You can add this to the list: 
CWBRN-20028
 
It's status is "Submitted To Development" and involves Reaktor sending on multiple MIDI channels.
 
It is described here:
 
X3 freezing because of MIDI routing?
 
http://forum.cakewalk.com...-routing-m2900977.aspx

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.

Even though I am sick to death of starting and re-starting my computer....I continue to tinker with this and basically get really inconclusive results that continue to mystify me.  But I really need to drop this and do something else, and that is what I am going to do.
 
I reported that Jamstix worked okay triggering multiple drums synths, now that same project just crashed.  Will it come back the next time and work or will it crash? Who knows, I really don't have the patience anymore to investigate this mess.
 
I give up wasting time making my computer crash over and over and will instead put my faith in CW that they know what the issue is and they will fix it.  However, i will have a giant bottle of Xanax ready when the fixed is announced and i sit down to try it out.  
 
JR
 

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.

OK well let's hope Cake can chirp in here... At the very least PM you...

thanks for all the hard work on this

SilkTone
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.

 
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" 

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.

I think what makes this very difficult to communicate on is the focus on "he said, she said" versus the specifics of the case. There's clearly a lot of history here, but quoting stories from several years ago is a bit inaccurate 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.
 
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. Allow me to explain a bit:
 
When we submit a Problem Report to our Development team, we're basically merging two systems (our internal bug tracking system and our problem report system on the website). Our developers do not use the Problem Report form. Why? Because a majority of the reports are not bugs and are actually support related questions. Therefore, Quality Assurance and Tech Support filter the cases. So, when we send something to development, we're trying to be as specific as possible, but we're really just tying the report to a case in our internal bug tracking system.
 
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.
 
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. 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. 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.
 
Whew!
 
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. Make sure it's descriptive (not to be a waste of time or insult IQs as we've been accused of ;) ) but rather just to make sure it goes through the system as quickly as possible. 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.
 
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. We actually do have some people on vacation at the moment, as well as several other projects, so our developers are a bit tied up at the moment. Part of the inactivity on my part, as well as from other Cakewalkers, is a result of that really.
 
Edit for typos

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).