• SONAR
  • Bugs and Fixes list (p.6)
2015/01/28 15:31:23
Taurean Mixing
Keni
Hi Gang...

I know I'm dying to see the list as well as order Platinum before the discount prices end... Which they are reluctant to give us the date and are opting to push us with announcements of ending soon... <sigh>...

I'm gonna buy it anyway. Even if my most needed fix(es) are not done... I'm broke and might lose my house any day, but Sonar is more important to me... So I'm scrambling to come up with even the $20 I need to get started with the (ugh) monthly plan...

I seem to remember there is usually a list of fixes included in the install notes? I guess not or not this time. Things are always changing...

The struggle to complete as many features and fixes prior to release is never easy and with releasing right before a major convention I'm sure there were many things last-minute-added/removed, so collecting the info is taking some time.

I too am very anxious to see it, but c'mon Gang... Cut 'EM some slack. A major release is a daunting task...

So too is the task of host moderator... Trying to keep the peace as well as accomplish the communication isn't easy... Adding a touch of humor is a welcome method for me. I didn't read any nasty intent to anything said...

Lighten up! We're not buying houses or corporations here! ;-)

Keni



First, sorry to hear about your financial problems Keni.
 
On to the point about publishing the bug fix list:
The problem with saying that there's a major convention is that it's using an excuse as an excuse. If you think about it, just because there is a major convention does not mean you halfheartedly release a major piece of software; especially one, even though loved by the users, is still harboring long-standing bugs. These are all executive, business decisions:, get it out fast, in time for NAMM. They don't necessarily benefit the efficiency of the software or the users' experience.
 
Or even taking Seth's comments into consideration about how it "takes time to compile it in a database." Even if you were to buy that, the point still remains: don't release it until it is finished! A software's publications of fixed issues, known issues, etc are just as crucial as the software itself, for a plethora of reasons, some even financial. If that isn't done, then it's not ready.
 
Regarding keeping the piece as a moderator: yea, I agree. When a person doesn't have the right cue for humor, you are doing everything but keeping the piece. You are agitating the situation. 
2015/01/28 16:04:09
Bristol_Jonesey
rtucker55
Bristol_Jonesey
rtucker55
Not likely as I don't use screensets. (knowingly)  As I stated the Cake support guy also duplicated the issue, on a New project, while we were on the phone.
 
Give it a shot, create a New project insert 3 midi blank midi tracks, Open the PRV, Pick the 3 midi tracks so they show in the PRV's track pane. Click the HIDE button for one of the tracks, save the project and close it. Open the project and all 3 will be showing vs. 2 showing 1 hidden, as expected.


Yes, confirmed.




Thanks Jonesey!
 
One more data point I trust...




I can also confirm that this behaviour persists whether you lock the screenset or leave it unlocked
2015/01/28 16:26:31
Keni
Thanks TM...

I'm sorry...

Keni
2015/01/29 13:07:31
stevec
Transcending Music


On to the point about publishing the bug fix list:
The problem with saying that there's a major convention is that it's using an excuse as an excuse. If you think about it, just because there is a major convention does not mean you halfheartedly release a major piece of software; especially one, even though loved by the users, is still harboring long-standing bugs. These are all executive, business decisions:, get it out fast, in time for NAMM. They don't necessarily benefit the efficiency of the software or the users' experience.
 
Or even taking Seth's comments into consideration about how it "takes time to compile it in a database." Even if you were to buy that, the point still remains: don't release it until it is finished! A software's publications of fixed issues, known issues, etc are just as crucial as the software itself, for a plethora of reasons, some even financial. If that isn't done, then it's not ready.
 



Having worked for a large software company for about 17 years now I would simply disagree with this.   Is a bug fix list important?   Yes.  Would we ever delay a release specifically to have the list available at the same time?  Heck no.  More users typically want the latest release as-is than would rely on the list to make that purchase decision.  
 
I'm trying to imagine Platinum still not having been released yet simply because the list wasn't ready...  And based on the way things have gone over the last few weeks, it sure seems that CW made the right decision.  It doesn't mean everyone has to agree, but it's hard to deny that the way the Platinum release was handled has thus far been a success.
 
2015/01/29 13:20:08
Taurean Mixing
stevec
Transcending Music


On to the point about publishing the bug fix list:
The problem with saying that there's a major convention is that it's using an excuse as an excuse. If you think about it, just because there is a major convention does not mean you halfheartedly release a major piece of software; especially one, even though loved by the users, is still harboring long-standing bugs. These are all executive, business decisions:, get it out fast, in time for NAMM. They don't necessarily benefit the efficiency of the software or the users' experience.
 
Or even taking Seth's comments into consideration about how it "takes time to compile it in a database." Even if you were to buy that, the point still remains: don't release it until it is finished! A software's publications of fixed issues, known issues, etc are just as crucial as the software itself, for a plethora of reasons, some even financial. If that isn't done, then it's not ready.
 



Having worked for a large software company for about 17 years now I would simply disagree with this.   Is a bug fix list important?   Yes.  Would we ever delay a release specifically to have the list available at the same time?  Heck no.  More users typically want the latest release as-is than would rely on the list to make that purchase decision.  
 
I'm trying to imagine Platinum still not having been released yet simply because the list wasn't ready...  And based on the way things have gone over the last few weeks, it sure seems that CW made the right decision.  It doesn't mean everyone has to agree, but it's hard to deny that the way the Platinum release was handled has thus far been a success.
 




Hey Steve,
 
Either way is speculation. We can only gauge the success of it having been released because it's been released.
Conversely, one can only imagine if success would've been better if the list was released. Further, the premise of the "software's release" is invented, it's not some event that is coming and one must plan around it as if it is out of their control. When you say "would we delay a release, absolutely not," you are merely saying that a company is not willing to comply for the benefit of all users, for the sole benefit of the company, that's all that means. If Cakewalk never announced a release for the given date, it's a non-issue; there is nothing to be waiting for. By your logic, a demonstration of some success means that all perpetual releases should be released before they are released to ensure this one-dimensional success.
 
Bottom line: have the transparency of the condition of the software ready along with your release. Those who would've bought it regardless, will buy it. Those who find the list important will now also be able to make an informed decision. Everybody is happy.
 
This paradigm has worked before.
 
Btw, OT: are you the one with the Nebula and CPU discrepancy vs. Reaper? I can confirm that as well.
2015/01/29 13:41:56
Splat
stevec
 
Having worked for a large software company for about 17 years now I would simply disagree with this.   Is a bug fix list important?   Yes.  Would we ever delay a release specifically to have the list available at the same time?  Heck no.  More users typically want the latest release as-is than would rely on the list to make that purchase decision.  



Ditto - release early release often right? Pretty standard in the software industry. You've still got to keep on it though as an iterative approach, otherwise it gets out of control. People who are not familiar should check out agile development methodology....
 
BTW there is no issue about the list not being released, it will happen it's just not ready yet. The way some people are writing it's like they think cakewalk is holding back on purpose or something... 100% wrong if you read what they have said. Sorry you can't have your cake and eat it right now. If it worries you that much then don't buy Sonar until that list is published. Simple.
2015/01/29 19:19:17
jatoth
Really?
It takes time to compile the list? It takes time to enter them in a database?
By Seth's own account, "(took about 5 minutes to compile.) There's at least 380 resolved issues that are tagged as customer reported."
How long SHOULD it take to enter 380 issues into a database (they are already in the "known issues" database)? I know, 380 was just Seth's rough quick count. How long should it take to enter 3,000? Days? Weeks? Months? Didn't an actual programmer resolve each issue and mark it as fixed? If so each programmer already had a "fixed issue" list of their own. Didn't management allocate resources for certain bugs to be fixed? That is what we are told when we question Staff View bugs. Well, if resources were allocated to fix "certain bugs", then where is the progress report for management stating "these bugs were fixed"?
Now, maybe they're waiting for the "accidental bug fix list". That would make some sense. After all, we don't know what bugs may have been fixed in the process of re-writing some modules.
And testing takes time. Oops, the program was already thoroughly tested, scratch that.
 
All we are asking for is a list of the bugs you know you have fixed. I'm sorry, that just can't take weeks or even days.
 
We only speculate because what we are told (or not told) does not make sense.
2015/01/29 20:14:27
mudgel
Cakewalk used to release a bug fix document which also contained a list of known issues. BUT it was never available before the release it was part of the release. Meaning you had to buy the product to get the list. No benefit to someone except to come to the forum and ask those who had taken the plunge.
2015/01/29 20:53:39
Keni
CakeAlexS
stevec
 
Having worked for a large software company for about 17 years now I would simply disagree with this.   Is a bug fix list important?   Yes.  Would we ever delay a release specifically to have the list available at the same time?  Heck no.  More users typically want the latest release as-is than would rely on the list to make that purchase decision.  



Ditto - release early release often right? Pretty standard in the software industry. You've still got to keep on it though as an iterative approach, otherwise it gets out of control. People who are not familiar should check out agile development methodology....
 
BTW there is no issue about the list not being released, it will happen it's just not ready yet. The way some people are writing it's like they think cakewalk is holding back on purpose or something... 100% wrong if you read what they have said. Sorry you can't have your cake and eat it right now. If it worries you that much then don't buy Sonar until that list is published. Simple.


I agree with both of you... Well spoken!

Some people see conspiracy everywhere... Not saying there aren't any, but sometimes you have to trust someone, someplace... Cakewalk has Akways earned my respect and I am inclined to give them the benefit of the doubt...

Keni
2015/01/30 08:50:25
Taurean Mixing
jatoth
Really?
It takes time to compile the list? It takes time to enter them in a database?
By Seth's own account, "(took about 5 minutes to compile.) There's at least 380 resolved issues that are tagged as customer reported."
How long SHOULD it take to enter 380 issues into a database (they are already in the "known issues" database)? I know, 380 was just Seth's rough quick count. How long should it take to enter 3,000? Days? Weeks? Months? Didn't an actual programmer resolve each issue and mark it as fixed? If so each programmer already had a "fixed issue" list of their own. Didn't management allocate resources for certain bugs to be fixed? That is what we are told when we question Staff View bugs. Well, if resources were allocated to fix "certain bugs", then where is the progress report for management stating "these bugs were fixed"?
Now, maybe they're waiting for the "accidental bug fix list". That would make some sense. After all, we don't know what bugs may have been fixed in the process of re-writing some modules.
And testing takes time. Oops, the program was already thoroughly tested, scratch that.
 
All we are asking for is a list of the bugs you know you have fixed. I'm sorry, that just can't take weeks or even days.
 
We only speculate because what we are told (or not told) does not make sense.



Keni
CakeAlexS
stevec
 
Having worked for a large software company for about 17 years now I would simply disagree with this.   Is a bug fix list important?   Yes.  Would we ever delay a release specifically to have the list available at the same time?  Heck no.  More users typically want the latest release as-is than would rely on the list to make that purchase decision.  



Ditto - release early release often right? Pretty standard in the software industry. You've still got to keep on it though as an iterative approach, otherwise it gets out of control. People who are not familiar should check out agile development methodology....
 
BTW there is no issue about the list not being released, it will happen it's just not ready yet. The way some people are writing it's like they think cakewalk is holding back on purpose or something... 100% wrong if you read what they have said. Sorry you can't have your cake and eat it right now. If it worries you that much then don't buy Sonar until that list is published. Simple.


I agree with both of you... Well spoken!

Some people see conspiracy everywhere... Not saying there aren't any, but sometimes you have to trust someone, someplace... Cakewalk has Akways earned my respect and I am inclined to give them the benefit of the doubt...

Keni

 
What is well spoken about that? Are you kidding? They merely regurgitated the status of "normal" operation. They didn't actually make a point. So what are you agreeing about? You are agreeing on these things:
 
- forget the user
- stick to the business schedule for release
 
lol That's the problem with these parts: sycophantism. One can respect and back a company, be a huge fan and user of their software, and yet still reasonably question things from time to time. Things in fact that would help their business. I've been a Sonar user longer than I've been a member of this forum!
 
And no it's not about conspiracies; there's zero need to reduce our reasonable request to a type of hysteria. There is a conduct or way of handling this that is being pointed out.
 
There's NO reason the bug list can't be released with the software. Even IF that meant releasing it at another date. IF there is no announcement of an earlier date, there is no anticipation for a release on THAT date.
 
Bottom line: have the transparency of the condition of the software ready along with your release. Those who would've bought it regardless, will buy it. Those who find the list important will now also be able to make an informed decision. Everybody is happy.
 
This paradigm has worked before.
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account