|
|
Post by marcl on Feb 11, 2022 8:06:52 GMT -5
The main reason why we've virtually stopped providing any sort of dates IS because we DO get so much flack when we miss them. Really no offense, but wouldn´t it make more sense and generate more benefit to improve with planning and assessing then just not set and communicate dates anymore? Speaking in IEEE 1044 terms, you are fixing one problem but not the defect, which is causing this and other problems as a root cause. Or in Agile terms, "Technical Debt" ... which can be a tool if used strategically, but more often is unintentional and can build over time and be very difficult to resolve. From my observations the past couple years, there's been a bit of both. Here's an explanation, in pretty non-technical terms: www.productplan.com/glossary/technical-debt/#:~:text=Technical%20debt%20(also%20known%20as,speedy%20delivery%20over%20perfect%20code. (Watch the video, but click the Skip button a few seconds into it) I would agree with KeithL that it's a bad idea to give dates because it's so hard to estimate how long it will take to fix a defect. Probably harder than estimating development of new features. An experienced team can learn to estimate new development quite accurately. But estimating bug fixes is more like estimating how long it will take to catch a murder suspect, particularly if the team hasn't mastered the process of estimating new development. And when new development is happening on a platform which has intrinsic technical debt, the whole thing is compounded. Bottom line: in business the boss will hold a virtual gun to the collective head of the development team and ask for the impossible ... a date! They have no choice, and will suffer the inevitable wrath of the boss. We should be more realistic and respectful and just ask for a description of the problem ... and then wait patiently for the resolution. |
|
|
|
Post by hsamwel on Feb 11, 2022 11:09:00 GMT -5
“I think you misunderstand what we want.” What I would like to know is where the “WE” is coming from? No bad feelings intended. I would refrain from grandstanding on behalf of other forum members that MAY part company with much that’s here in this thread. Sorry, didn’t mean for it to come out like that. Should have written ”I” instead.. |
|
|
|
Post by 405x5 on Feb 11, 2022 11:20:56 GMT -5
What I would like to know is where the “WE” is coming from? No bad feelings intended. I would refrain from grandstanding on behalf of other forum members that MAY part company with much that’s here in this thread. Sorry, didn’t mean for it to come out like that. Should have written ”I” instead.. Ha! (No worries at all) |
|
|
|
Post by hsamwel on Feb 11, 2022 11:23:18 GMT -5
Really no offense, but wouldn´t it make more sense and generate more benefit to improve with planning and assessing then just not set and communicate dates anymore? Speaking in IEEE 1044 terms, you are fixing one problem but not the defect, which is causing this and other problems as a root cause. Or in Agile terms, "Technical Debt" ... which can be a tool if used strategically, but more often is unintentional and can build over time and be very difficult to resolve. From my observations the past couple years, there's been a bit of both. Here's an explanation, in pretty non-technical terms: www.productplan.com/glossary/technical-debt/#:~:text=Technical%20debt%20(also%20known%20as,speedy%20delivery%20over%20perfect%20code. (Watch the video, but click the Skip button a few seconds into it) I would agree with KeithL that it's a bad idea to give dates because it's so hard to estimate how long it will take to fix a defect. Probably harder than estimating development of new features. An experienced team can learn to estimate new development quite accurately. But estimating bug fixes is more like estimating how long it will take to catch a murder suspect, particularly if the team hasn't mastered the process of estimating new development. And when new development is happening on a platform which has intrinsic technical debt, the whole thing is compounded. Bottom line: in business the boss will hold a virtual gun to the collective head of the development team and ask for the impossible ... a date! They have no choice, and will suffer the inevitable wrath of the boss. We should be more realistic and respectful and just ask for a description of the problem ... and then wait patiently for the resolution. In most I do agree. With information everything would be a lot calmer here.. But to accknowledge and actual bugfixing for an experienced team should not take ONE YEAR.. IMO! And Emotivas team is experienced atleast. How good they are I can’t tell. How fast it takes to code depends on a lot of factors. |
|
|
|
Post by ElectricKoolAid on Feb 11, 2022 11:31:47 GMT -5
What I would like to know is where the “WE” is coming from? No bad feelings intended. I would refrain from grandstanding on behalf of other forum members that MAY part company with much that’s here in this thread. Sorry, didn’t mean for it to come out like that. Should have written ”I” instead.. I think the "we" is the collective "we" of those who have expressed similar desires/complaints/gripes/suggestions. I know I fall into that camp as well at times. |
|
|
|
Post by bolle on Feb 11, 2022 11:38:39 GMT -5
Really no offense, but wouldn´t it make more sense and generate more benefit to improve with planning and assessing then just not set and communicate dates anymore? Speaking in IEEE 1044 terms, you are fixing one problem but not the defect, which is causing this and other problems as a root cause. Or in Agile terms, "Technical Debt" ... which can be a tool if used strategically, but more often is unintentional and can build over time and be very difficult to resolve. From my observations the past couple years, there's been a bit of both. Here's an explanation, in pretty non-technical terms: www.productplan.com/glossary/technical-debt/#:~:text=Technical%20debt%20(also%20known%20as,speedy%20delivery%20over%20perfect%20code. (Watch the video, but click the Skip button a few seconds into it) I would agree with KeithL that it's a bad idea to give dates because it's so hard to estimate how long it will take to fix a defect. Probably harder than estimating development of new features. An experienced team can learn to estimate new development quite accurately. But estimating bug fixes is more like estimating how long it will take to catch a murder suspect, particularly if the team hasn't mastered the process of estimating new development. And when new development is happening on a platform which has intrinsic technical debt, the whole thing is compounded. Bottom line: in business the boss will hold a virtual gun to the collective head of the development team and ask for the impossible ... a date! They have no choice, and will suffer the inevitable wrath of the boss. We should be more realistic and respectful and just ask for a description of the problem ... and then wait patiently for the resolution. "Technical debt" is actually something entirely different than I was describing. Based on your background you stated here in the boards I suppose you know that. So you are more kind of "siderailing".  Regarding my original point, I respectfully disagree. Of course, an estimate is an estimate and not exact science, but normally you iteratively get better with estimating when doing the same thing again and again. You will never remove the margin of error entirely, but it gets reasonably small. I don´t see this here, I am following Emotivas processor development since the UMC-200 (owned one and still own my XMC-1) and they are still behind dates/schedules by a mile imho. For me just not communicating dates anymore isn´t fixing the real problem in any way. If a major bug exists and it doesn´t get fixed for months, customers will get unhappy, regardless if you provide a date for the fix or not. If you also take a step back, the same is happening with the expansion modules for the RMC-1 and I am sure other users will have other examples ready. |
|
|
|
Post by marcl on Feb 11, 2022 11:51:39 GMT -5
Or in Agile terms, "Technical Debt" ... which can be a tool if used strategically, but more often is unintentional and can build over time and be very difficult to resolve. From my observations the past couple years, there's been a bit of both. Here's an explanation, in pretty non-technical terms: www.productplan.com/glossary/technical-debt/#:~:text=Technical%20debt%20(also%20known%20as,speedy%20delivery%20over%20perfect%20code. (Watch the video, but click the Skip button a few seconds into it) I would agree with KeithL that it's a bad idea to give dates because it's so hard to estimate how long it will take to fix a defect. Probably harder than estimating development of new features. An experienced team can learn to estimate new development quite accurately. But estimating bug fixes is more like estimating how long it will take to catch a murder suspect, particularly if the team hasn't mastered the process of estimating new development. And when new development is happening on a platform which has intrinsic technical debt, the whole thing is compounded. Bottom line: in business the boss will hold a virtual gun to the collective head of the development team and ask for the impossible ... a date! They have no choice, and will suffer the inevitable wrath of the boss. We should be more realistic and respectful and just ask for a description of the problem ... and then wait patiently for the resolution. "Technical debt" is actually something entirely different than I was describing. Based on your background you stated here in the boards I suppose you know that. So you are more kind of "siderailing".  Regarding my original point, I respectfully disagree. Of course, an estimate is an estimate and not exact science, but normally you iteratively get better with estimating when doing the same thing again and again. You will never remove the margin of error entirely, but it gets reasonably small. I don´t see this here, I am following Emotivas processor development since the UMC-200 (owned one and still own my XMC-1) and they are still behind dates/schedules by a mile imho. For me just not communicating dates anymore isn´t fixing the real problem in any way. If a major bug exists and it doesn´t get fixed for months, customers will get unhappy, regardless if you provide a date for the fix or not. If you also take a step back, the same is happening with the expansion modules for the RMC-1 and I am sure other users will have other examples ready. We're on the same page. I guess I was trying to make the point that these issues are process issues. They COULD be solved, but every decision on use of resources has business consequences and one company will make these decisions differently than another. For example, Dirac has a system to log issues directly into their customer support system. They give it a number and they respond. Every time. Two weeks ago they released V3.20 which had a major bug and they fixed it within days. Then a LOT of people complained that they had restricted correction to a lower limit of 20Hz. They changed it in less than a week. Emotiva can't or won't work this way for reasons known only to them. But ultimately you are right. Not giving a date doesn't solve the issue. I'm reminded of my last employer before I retired. I came from many years of Agile process and was flung into the Dark Ages of traditional project management. They had two stages of approving a project to start. At the first stage the estimate was to be within 25%. At the final stage, 10%. I asked at a monthly project management meeting what process would yield 25% vs 10% ... of course there was no answer. But they found that every project was going over budget and schedule. So they changed the final stage requirement to 0%. That was the solution! |
|
cawgijoe
Emo VIPs 
"When you come to a fork in the road, take it." - Yogi Berra
Posts: 5,033
|
Post by cawgijoe on Feb 11, 2022 11:53:02 GMT -5
Or in Agile terms, "Technical Debt" ... which can be a tool if used strategically, but more often is unintentional and can build over time and be very difficult to resolve. From my observations the past couple years, there's been a bit of both. Here's an explanation, in pretty non-technical terms: www.productplan.com/glossary/technical-debt/#:~:text=Technical%20debt%20(also%20known%20as,speedy%20delivery%20over%20perfect%20code. (Watch the video, but click the Skip button a few seconds into it) I would agree with KeithL that it's a bad idea to give dates because it's so hard to estimate how long it will take to fix a defect. Probably harder than estimating development of new features. An experienced team can learn to estimate new development quite accurately. But estimating bug fixes is more like estimating how long it will take to catch a murder suspect, particularly if the team hasn't mastered the process of estimating new development. And when new development is happening on a platform which has intrinsic technical debt, the whole thing is compounded. Bottom line: in business the boss will hold a virtual gun to the collective head of the development team and ask for the impossible ... a date! They have no choice, and will suffer the inevitable wrath of the boss. We should be more realistic and respectful and just ask for a description of the problem ... and then wait patiently for the resolution. "Technical debt" is actually something entirely different than I was describing. Based on your background you stated here in the boards I suppose you know that. So you are more kind of "siderailing". Regarding my original point, I respectfully disagree. Of course, an estimate is an estimate and not exact science, but normally you iteratively get better with estimating when doing the same thing again and again. You will never remove the margin of error entirely, but it gets reasonably small. I don´t see this here, I am following Emotivas processor development since the UMC-200 (owned one and still own my XMC-1) and they are still behind dates/schedules by a mile imho. For me just not communicating dates anymore isn´t fixing the real problem in any way. If a major bug exists and it doesn´t get fixed for months, customers will get unhappy, regardless if you provide a date for the fix or not. If you also take a step back, the same is happening with the expansion modules for the RMC-1 and I am sure other users will have other examples ready. You definitely should get better estimating as time goes by. Emotiva has historically been slow in getting something out the door, or fixing something. I don't know what the reason for this is, but I'm sure there reasons for it. I still think no communication is bad. A simple update as to status every so often would help IMO. |
|
|
|
Post by bolle on Feb 12, 2022 5:48:37 GMT -5
We're on the same page. I guess I was trying to make the point that these issues are process issues. They COULD be solved, but every decision on use of resources has business consequences and one company will make these decisions differently than another. For example, Dirac has a system to log issues directly into their customer support system. They give it a number and they respond. Every time. Two weeks ago they released V3.20 which had a major bug and they fixed it within days. Then a LOT of people complained that they had restricted correction to a lower limit of 20Hz. They changed it in less than a week. Emotiva can't or won't work this way for reasons known only to them. But ultimately you are right. Not giving a date doesn't solve the issue. I'm reminded of my last employer before I retired. I came from many years of Agile process and was flung into the Dark Ages of traditional project management. They had two stages of approving a project to start. At the first stage the estimate was to be within 25%. At the final stage, 10%. I asked at a monthly project management meeting what process would yield 25% vs 10% ... of course there was no answer. But they found that every project was going over budget and schedule. So they changed the final stage requirement to 0%. That was the solution! I agree and can identify with everything you say from personal experience. Unfortunately I still have some way to go until retirement...  Enjoy yours! |
|
sealman
Minor Hero
You shouldn't have decorated your saloon with my friend!
Posts: 78 
|
Post by sealman on Feb 24, 2022 12:26:55 GMT -5
LOL….. I believe the answer to that question has been crystal clear ever since this thread got launched….(am I the only one who sees this?? 😂) I don't work for Emotiva and I certainly have been among those beating the drum (and I AM a drummer!) about this issue for a year now ... but it's fair to say they did well fixing the really BIG issue in FW2.5, and reliable sources suggest the final fix is in the works. I think we can now not beat them up anymore, at least until we hear the next FW release. While I get what you are saying I really don't agree with it due to the ridiculous amount of time it takes for them to ever address an issue. Also sometimes the issue is never fully fixed before the product goes end of life with them. I will be keeping my XMC-2 but this is the last prepro I will ever buy from them. Now that Dirac is out in the world there are many options to choose from that don't come with a 6k+ price tag. |
|
|
|
Post by geebo on Feb 24, 2022 12:51:28 GMT -5
I don't work for Emotiva and I certainly have been among those beating the drum (and I AM a drummer!) about this issue for a year now ... but it's fair to say they did well fixing the really BIG issue in FW2.5, and reliable sources suggest the final fix is in the works. I think we can now not beat them up anymore, at least until we hear the next FW release. While I get what you are saying I really don't agree with it due to the ridiculous amount of time it takes for them to ever address an issue. Also sometimes the issue is never fully fixed before the product goes end of life with them. I will be keeping my XMC-2 but this is the last prepro I will ever buy from them. Now that Dirac is out in the world there are many options to choose from that don't come with a 6k+ price tag. 6k+ ? |
|
sealman
Minor Hero
You shouldn't have decorated your saloon with my friend!
Posts: 78
|
Post by sealman on Feb 24, 2022 13:24:18 GMT -5
While I get what you are saying I really don't agree with it due to the ridiculous amount of time it takes for them to ever address an issue. Also sometimes the issue is never fully fixed before the product goes end of life with them. I will be keeping my XMC-2 but this is the last prepro I will ever buy from them. Now that Dirac is out in the world there are many options to choose from that don't come with a 6k+ price tag. 6k+ ? Prior to the XMC-2/RMC-1/L there was just the XMC-1 with Dirac for under 6K if my memory is working today. There was nothing close to the cost of the XMC-1's price for sure. |
|
|
|
Post by ElectricKoolAid on Mar 24, 2022 15:43:13 GMT -5
Happy 1 month anniversary from the last post in this thread. I don't have anything important to say, I guess it's nice that firmware 2.5 has at least mostly fixed the BM issue. My setup sounds pretty good overall so I can't complain too much. Would be nice to hear an update on the big upcoming firmware though.
|
|
|
|
Post by donh50 on Mar 24, 2022 16:20:04 GMT -5
Prior to the XMC-2/RMC-1/L there was just the XMC-1 with Dirac for under 6K if my memory is working today. There was nothing close to the cost of the XMC-1's price for sure. Options other than the XMC-1 were to buy the SW (~$300) and run it on a PC (an option long before the XMC-1), or use a miniDSP unit (not sure price now, was around $1k for the fancy HD unit) if you wanted Dirac Live. There were probably others but those are the ones I remember from a few years ago when I was looking at the XMC-1. There were also several higher-priced HW options, natch, and now we have additional options like REW and MSO that are free SW giving you great flexibility in what HW you use to implement the filters (I have seen PCs, miniDSPs, Raspberry PIs, and so forth). |
|
sealman
Minor Hero
You shouldn't have decorated your saloon with my friend!
Posts: 78
|
Post by sealman on Mar 25, 2022 14:14:30 GMT -5
Prior to the XMC-2/RMC-1/L there was just the XMC-1 with Dirac for under 6K if my memory is working today. There was nothing close to the cost of the XMC-1's price for sure. Options other than the XMC-1 were to buy the SW (~$300) and run it on a PC (an option long before the XMC-1), or use a miniDSP unit (not sure price now, was around $1k for the fancy HD unit) if you wanted Dirac Live. There were probably others but those are the ones I remember from a few years ago when I was looking at the XMC-1. There were also several higher-priced HW options, natch, and now we have additional options like REW and MSO that are free SW giving you great flexibility in what HW you use to implement the filters (I have seen PCs, miniDSPs, Raspberry PIs, and so forth). You are correct that those were options at the time. However none of those have the same abilities as a pre/pro with video switching along with other benefits and were capable of 7 channels of Dirac without implementing some workarounds. Edit: I also forgot that since none of the Mini DSP Dirac devices accept HDMI that also rules out the current lineup of audio codecs as well as all streaming devices unless you are okay with old school DD5.1 and don't care about any of the lossless codecs. |
|
|
|
Post by hsamwel on Mar 25, 2022 19:21:18 GMT -5
Same issue. The bass is pronounced with Dirac enabled or not enabled. Yes! ttocs in his initial post specifically did not use Dirac. In my posts I have Dirac enabled with flat target curves. The issue is the same. Changing target curves can make the issues worse, but not better. Yes, and quite illogical that it would affect Dirac only as Dirac does not handle BM or LFE levels at all.. Except for the house curves some uses. But these wouldn’t elevate themselves after a firmware..  |
|
|
|
Post by marcl on Mar 25, 2022 19:36:11 GMT -5
Yes! ttocs in his initial post specifically did not use Dirac. In my posts I have Dirac enabled with flat target curves. The issue is the same. Changing target curves can make the issues worse, but not better. Yes, and quite illogical that it would affect Dirac only as Dirac does not handle BM or LFE levels at all.. Except for the house curves some uses. But these wouldn’t elevate themselves after a firmware..  Before Dirac was available (June/July 2020), I found and reported a bug that had to do with how PEQ was applied to bass management. It was related to the bass management signal path. I'm betting that the current bass management bug is related to how that was fixed for PEQ, but maybe not properly fixed for Dirac ... or more likely, fixed in summer of 2020 and then broken again later. |
|
|
|
Post by hsamwel on Mar 28, 2022 3:39:41 GMT -5
Yes, and quite illogical that it would affect Dirac only as Dirac does not handle BM or LFE levels at all.. Except for the house curves some uses. But these wouldn’t elevate themselves after a firmware.. Before Dirac was available (June/July 2020), I found and reported a bug that had to do with how PEQ was applied to bass management. It was related to the bass management signal path. I'm betting that the current bass management bug is related to how that was fixed for PEQ, but maybe not properly fixed for Dirac ... or more likely, fixed in summer of 2020 and then broken again later. Wasn’t that the order of when PEQ was added to the signal path? If I remember correctly in some configurations they added PEQ after BM? Or was it before? |
|
|
|
Post by marcl on Mar 28, 2022 6:03:35 GMT -5
Before Dirac was available (June/July 2020), I found and reported a bug that had to do with how PEQ was applied to bass management. It was related to the bass management signal path. I'm betting that the current bass management bug is related to how that was fixed for PEQ, but maybe not properly fixed for Dirac ... or more likely, fixed in summer of 2020 and then broken again later. Wasn’t that the order of when PEQ was added to the signal path? If I remember correctly in some configurations they added PEQ after BM? Or was it before? Yes some configurations had PEQ added before BM so the BM signal was not affected. It was when you configured no subs and sent LFE and BM to large fronts. This is still an issue in a different way as part of the current BM bug. Seems like the coding always assumed there would be at least one sub.  |
|
ttocs
Global Moderator 
I always have a wonderful time, wherever I am, whomever I'm with. (Elwood P Dowd)
Posts: 8,154
|
Post by ttocs on May 19, 2022 9:27:50 GMT -5
marclI figured we should try to figure this out in this thread. Please post your REW findings here so we can discuss.
|
|
Enjoy yours!
