I really need clarification on this issue from CW. There are now many conflicting reports.

Those threads were an interesting topic for me, so going from memory...  I believe that the crash was resolved specifically with Jamstix, and that the variant was Catanya; i.e., that there's something different about the way each plugin was causing a crash that required two different (but possibly related) fixes.
 
I don't recall whether stuck notes had come up in those discussions.
 

I wonder if their testers have a copy of reaktor? That would be a great one to test with since it's so popular.

I feel your pain, I've been waiting for this for a long long time. When i first discovered it I found your website and was blown away that it was documented so well.

The lack of midi routing is my number one thing with sonar. I imagine it's an extensive painful fix to implement and so it gets pushed to the side.

BTW initial reaction ... I can totally understand this... Believe me I get it.... I mock and totally understand at the same time.
 

Mystic38
I suspect you have a simplistic, (though very reasonable) view of the interactions between daws and plugins.
 

 
You probably don't know this but I've been writing VST plugins for many years, and doing software development for even longer (25+ years). So my view is anything but simplistic, I just didn't want to go into technical details.
 
From a developer's point of view, the plugin is following the VST specification, and as such if it sends out MIDI notes, it is doing it within the VST specification using the buffer format as specified in that spec. Because of this, the host should not need to have different fixes for different plugins (this is what I mean with black box). If Sonar needs different fixes for different plugins in order not to crash, there are bigger problems than any of us suspected.
 
I eluded in some older threads about "spaghetti code". I'm not saying Sonar is spaghetti code, just that if it is isn't architecture in a well-defined, modular way, then this is the kind of problems you run into. You fix one thing and something else breaks. Simple bugs become difficult to fix. Complex bugs become impossible to fix. Once again not saying Sonar is this way, just observing the symptoms from the outside here...

mudgel
Isn't it the case that despite there being a standard that some developers don't stick to it as strictly as others. Hence the variations in interaction between plugins in the same or different hosts.

 
Yes that is very true. However these same plugins work fine in other DAWs so they can't be that far off.
 
I think more common is that some plugins use different parts of the spec for which the host has not been tested very well. A good example is the MIDI out feature. It is not that common (as say, audio out), which is why I don't think CW did that much testing with it. It doesn't help that CW say in their problem report instructions not to include 3rd party plugins. This makes it very difficult to impossible to file bugs of this nature because you can't reproduce it without 3rd party plugins. At the same time it makes it easy for CW to say it is buggy 3rd party plugins, which has been the standard response for many years.
 
It did take me a while to realize the bug is in Sonar and not the plugins. But while I was searching around the web back then looking for solutions to my problem, I remember finding a plugin developer's website where they stated something along the lines of "Sonar's MIDI implementation is a mess". That pretty much confirmed it for me. I looked for that website later again but could not for the life of me find it again. I should have created a link.

If it is closed personally I would create a brand new updated issue try to avoid past references. The problem with bug tracking is logs can get muddled out of proportion and sometimes it is good to start afresh on less tired eyes... Even if it means copying and pasting the first post into the issue to save time.
 
This is a great post I wish I read it properly first time around......
This emphasises the point really that Cake should be concentrating on bugfix and performance tweaks rather than enhancements first. There is clearly a backlog.

CakeAlexS
If it is closed personally I would create a brand new updated issue try to avoid past references. The problem with bug tracking is logs can get muddled out of proportion and sometimes it is good to start afresh on less tired eyes... Even if it means copying and pasting the first post into the issue to save time.
 
This is a great post I wish I read it properly first time around......
This emphasises the point really that Cake should be concentrating on bugfix and performance tweaks rather than enhancements first. There is clearly a backlog.

I don't know, I feel I've given CW enough info at this point. If they want to go ahead and close the bug reports due to being clueless about this issue then I'm not going to keep herding them like sheep into the right direction. I'm done with that.
 
Let me explain why I say that. And I know some people are tired of me rehashing this, and those people are free to ignore this post or this whole thread. I just feel that asking to re-submit a new problem report is a bit much, given that I:
 

• Logged an official problem report on Feb 24 2009, CWBRN-1336.
• Spent a large amount of time investigating this issue inside a debugger, as far as one could without having actual Sonar source code.
• Created a website that describes the bug(s) in detail, and linked it in the above mentioned problem report.
• Added clear steps to reproduce the issue to the website.
• Added screenshots to the website showing the resulting MIDI crosstalk in detail.
• Added a Sonar project to the website that can be used to reproduce the bug(s).
• Wrote a plugin stripped to the bare minimum that can be used to isolate the problem.
• Added the plugin as well as the plugin source code to the website so that CW can easily step through the plugin code to isolate the bug(s).
• Logged CWBRN-2504 on Feb 9 2010 with additional steps to reproduce this to help CW track down this issue. This one is about Sonar crashing with multiple instances of Catanya. Remember Noel said this wasn't "in the system".
• Logged CWBRN-2534 on Feb 16 2010 with additional steps to reproduce this to help CW track down this issue.
• Logged CWBRN-2532 on Feb 16 2010 with additional steps to reproduce this to help CW track down this issue.
• Called CW tech support at least twice to see if I can help them reproduce the problem.
• Had 15 email discussions with "Willy Jones" at CW, in which he promises that CW is looking into the issue and that it will be addressed in "an upcoming release". I offered multiple times to help track down the bug by doing beta testing for CW since I was very familiar with the issue. The first email was sent on Nov 23, 2009, the last response was on June 17 2011. My last reply was on Jan 2 2013 for which I have not received a response back.
• Provided the CBRN number to Noel Borthwick, CTO, Cakewalk on July 12 2009 who acknowledged the detailed information and posted "... We appreciate the detailed information you provided and we will investigate this in due time...."

 
So now after all that, CW erroneously closes the problem reports I filed, and if I follow your suggestion, the next bullet point in my list would become:
 

• Start the whole process all over again.

 
I hope you see why I don't want to do that. Nothing I've done from the above list has resulted in us being closer to a fix for this issue. CW is just as clueless about this as they were 5 years ago.
 
Here is something I know that does work:
 
A few years ago there was a review of Sonar (I think it was CM IIRC) . They ran into the bug where recording from multiple MIDI inputs would cause crosstalk between the tracks. This was posted in the magazine, and you won't believe how fast that bug got fixed! Unfortunately it turned out it wasn't related to the original bug referring to crosstalk from VSTi outputs into other tracks, so that bug (or bugs) was never fixed. Instead, the typical response from CW when bringing up this issue is similar to Ryan Munnis's response here:
 

The sarcasm isn't exactly helpful. We fix a bug you reported and this is the response we're getting? I don't understand.

 
He doesn't understand the sarcasm. I had to chuckle at that. I also cried a little.
 
Back to my story... Now my wish is that instead of the usual fluffy tests with the typical glowing reviews (remember CW advertises in those magazines), some of these reviewers can do an actual real review and bother to use the VSTi MIDI out feature with multiple plugins. And that Sonar then pukes MIDI notes all over other tracks like it has been doing for years, and crashes endlessly for them like it has been doing for years. And then the reviewer wondering why Sonar failed MIDI Routing 101. And then post about it in the magazine.
 
Only then will we see CW getting a clue about this issue, quickly fix it for the next review, and then act as if it's the 1st time they ever heard about it.
 
Because as I said we are no closer to a fix today than we were 5 years ago.

thanks for all the hard work on this

sharke
You said it yourself back in Jan of 2010 http://forum.cakewalk.com/FindPost/1924356
 
Sorry couldn't resist - I had to Google "Sonar MIDI implementation mess" 

You are correct sir, I did say that .  I think it stuck in my head ever since I originally read it from whatever that mystery site was. Maybe because it describes Sonar's MIDI so succinctly.

Ryan Munnis [Cakewalk]
I think what makes this very difficult to communicate on is the focus on "he said, she said" versus the specifics of the case.

 
This isn't about "he said, she said". The facts are pretty clear in this case, even if you need to spend a bit of time understanding the issue.
 

There's clearly a lot of history here, but quoting stories from several years ago is a bit inaccurate...

 
Sorry, these are not "stories". These are facts. In another thread you said I argued the facts about a bug that was marked as fixed. The problem is that you don't understand the full picture so you believe I've got my facts wrong. I've spent much more time on this for a much much longer time than you so the last thing you can accuse me of is not getting the facts straight.
 

...with the current release given the fact that we've checked in updates to SONAR and third-party plug-in devs have done the same. It seems like a wasted effort to read all of this history versus just talking about today's reality.

 
Well I'm sorry if you feel it is a wasted effort to spend some time understanding the issue. Today's "reality" is just like the reality 5 years ago, meaning the exact same issues still exist.
 

CWBRN-1336 is really just a link to the website, which has multiple issues listed, so logistics-wise it makes it a bit weird to process the case.

 
Sorry that I provided "just" a link. Are you suggesting instead that I should have put all that analysis, screenshots, source code and Sonar project into your problem report? The problem report can't even format simple paragraphs properly, so reading that much detail in it would have made it even more confusing. I'm not even sure what its text-limit is but I doubt it would have accepted all the text that is on the website. It is a bit insulting when you suggest I somehow provided a sub-par report since I provided "just" a link.
 

As developers resolve issues in our code base, they check in changes to our internal bug tracking system. The history shows up in the bug so we can see work has been done in a specific area. This lets our testers regress bugs and see if the information in the report is resolved. If it is resolved, they close the case as "fixed".
 
There is another automated process that performs a match on cases "Fixed" in our internal system with cases "Submitted to Development" in our Problem Report system. Most of it is automated. The only part that currently isn't automated is the part where we email notification that a fix is available. It's almost fully automated (sends a stock email) but it still requires some human intervention. In any case, I'm only discussing all of this because CWBRN-1336 had changesets checked in from our developers as well as notes from our testers that the behavior couldn't be replicated anymore. This prompted me to update CWBRN-1336 to say fixed. There are for real fixes and changes check in that we mentioned in the update notes. I think the problem though, is that CWBRN-1336 was too broad to be honest.

 
I have provide proof that those bugs are still reproducible. You made a mistake in closing it.
 
Let me explain CWBRN-1336 a bit since you find it a wasted effort to read it... This particular bug is difficult to quantify. There are many symptoms and it's hard to tell which symptom is part of the same underlying bug. CWBRN-1336 is an attempt to group together a set of behaviors that seem to point to the same bug (all related to crosstalk from VSTi MIDI out into other tracks). It lists 3 different ways to reproduce incorrect behavior that seem to be the result of the same underlying issue.
 
So what happened is that a bug was fixed for "hung" notes, and the release notes mentions CWBRN-1336. Well, CWBRN-1336 does mention stuck notes in one case, however that is nowhere near what it is all about. If your developers bothered to follow the steps in CWBRN-1336 they would most certainly have been able to reproduce the issue. So to this day, it is most certainly not fixed.
 

Now, with that being the case, if there are still issues and people are seeing mixed results, I could just re-open the report, but I'm not sure at this stage of the game it's very helpful. It's going to take us down the same path.

 
Not very helpful? Your developers claim they could not reproduce the issue, yet we see now that this issue has not been fixed (that is why I listed the "stories" as you say). If your developers actually bothered to follow the detailed steps in that report, they would most certainly reproduce the issue, I guarantee it. So you should re-open it.
 

What we probably should have done years ago when the report came in initially was what we do now, which is to break the CWBRN into unique cases identifying each bug.

 
Who should do that? Me? Sorry I spent enough of my time trying to help CW reproduce and fix this issue, only to have the problem reports now erroneously closed. Thanks, that really makes me feel good after putting in all those hours documenting this issue in painstaking detail! So I'm done with that. Good luck with reports that simply say..."I recorded MIDI and there were notes on there that should not be there".
 
At this point I don't even have an up-to-date version of Sonar anymore because I refuse to pay for yet another upgrade that is just as broken as it always has been. Because of that I don't even think I can log new reports even if I was stupid enough to waste more time doing so. I can't even tell what has been fixed and what not, so at this point I'm relying on other users to confirm what has been fixed and what not. I offered multiple times to do beta for testing for CW since I had good knowledge of the issues and how to reproduce them, but CW never bothered. I'm still open to that.
 

That's a pretty old report, back before we built any of these automated systems. At the time, actually, that case was no more complicated then an email inbox. Our system is much more advanced now. With it being more advanced now though, we're a bit more meticulous about logging specific reports identifying exact behavior versus multiple bugs in a single report.

 
So because it is old, the info it contains is useless? The bug is even older, so how is the info useless?
 

I think what we should do moving forward is that if someone is finding a behavior at all related to VSTi MIDI out, we should log a new report identifying the behavior.

 
Well good luck with that. I know that many people have logged reports regarding this same issue. None of it went anywhere, so I'm not sure what it would help to keep doing it over and over.
 

I promise you folks nobody in support is trying to brush issues off and make cases disappear. If you think we're being difficult and asking too many questions, it's probably a good thing versus us not asking for specifics and kicking the can down the road.

 
That has not been even close to my experience with this issue. CW has been pretty much ignoring this issue, even after multiple promises that this issue was being looked into, including promises from Noel many years ago. I have more quotes if you don't believe me, but I guess that will qualify as "he said, she said"...
 

For what it's worth, I have passed along this thread as well as the other two threads regarding VSTi MIDI out to developers internally. They're aware of the discussions.

That is the only bit of good news out of all of this. However, believe it or note, I have even more quotes where more or less the same thing was said. That was many years ago, so I'm not going to get all excited about the latest promises...
 
To summarize:

• I really think you should re-open CWBRN-1336. Unless you have another problem report that contains more detailed info, CWBRN-1336 has many details that can be used to verify that the issue(s) has been fixed.
• CWBRN-2504 was also closed in error. It specifically mentions multiple instances of Catanya crashing Sonar. We know for a fact that is has not been fixed, based on Lance Riley reporting here that he could reproduce it. Maybe Sonar doesn't crash with Jamstix anymore, but it certainly still crashes with Catanya, exactly as CWBRN-2504 describes. Do you disagree with re-opening it, and if so, why?
• Against my better judgment and after all the time I already wasted on this (with nothing to show in return other than having my efforts minimized by incorrectly closing the reports as "fixed"), I'm still offering to help CW resolve this issue. I have the means to test this in great detail because I'm very familiar with all the different symptoms (whether from the same bug or from different bugs).

I will go and make a shark sandwich.

 
I must say, SilkTone, I'm pretty impressed by your perseverance.
 
I hope things are eventually resolved to your liking.  Please keep us informed of any progress you achieve.
 

As Ryan indicated there were issues fixed with MIDI out. There was a well defined deadlock that *was* fixed in X3 as well as crashes related to MIDI out. So saying nothing was done in this area is grossly inaccurate.
There is a residual issue still on our radar with how MIDI echo is handled in combination with MIDI out VST's. I'm assuming that that is the residual problem that you still see and we will continue to investigate it.
 
 

Having worked in software tech support for the last 16 years, I can only echo one aspect that Ryan stated above that wasn't done from the beginning with this one - each individual issue/symptom/workflow has to have a unique bug #.   When rolling similar scenarios into one report, the chances of resolving them all diminishes - right or wrong, that just tends to happen when dealing with a revolving list of issues to troubleshoot. 
 
But it sounds like the CW folks are at that point now and have the ability to better manage the data associated with each remaining aspect of "MIDI crosstalk".    That's a pretty big step forward IMHO. 
 

As Ryan  (and I said before that) the only real way to go is to log a new reproducible bug with Sonar X3C, and start from scratch avoiding the old baggage (it may just be a simple cut and paste affair with a few alterations). This issue was logged three years ago, the people who made the decision to close it then may not even work for Cake anymore or work in different departments, or maybe there was a completely different process.
 
Forget the past, deal with it and start from scratch. Get over the hump...
In the land of QA it can be extremely difficult to reopen issues, esp when it's down to internal politics, much easier to start a new one. I entirely understand the frustration but that has to be the clear way forward.