Yendor
I finally received a note from 7alens, too, saying that they're looking into it.
I submitted a ticket to Cakewalk, regarding this: CWBRN-2296 just not sure how it will be handled.
Greysound, saw your add to the "Cakewalk, any new info on THESE bugs"
http://forum.cakewalk.com/tm.aspx?m=1643436&high=enable+midi+output+bug
I tried to add some additional detail to the ticket, but no dice thus far. I suggest another Sonar/Catanya user add another ticket, specifying the above thread.
Interesting. I was just reading through this thread and was going to post a comment that I believe this is related to the issue I posted on that website, but you beat me to it!
So this is the first time I have read about confirmed crashes related to this issue. On the website I speculated that I believe it could cause crashes, but it was only a theory at that time. This is a
serious bug, but unfortunately Cakewalk seems to completely ignore it, even after it has been brought to their attention a long time ago. I think the reason is because you cannot reproduce this problem without using a 3rd-party VSTi because there is no VSTi that ships in Sonar that sends MIDI out (where you need to check "Enable MIDI Output" on it). And because you always need a 3rd party VSTi, Cakewalk can conveniently say it is not their problem.
Personally I run into this problem every day. You need just one plugin sending MIDI output to experience the problem. When I have a VSTi sending MIDI out, and I record MIDI on a completely unrelated MIDI track using my MIDI controller, I constantly get notes that are cut short, missing notes, etc in the recorded clip. I have to go to the VSTi sending MIDI notes out and completely disable it in order to successfully record MIDI on unrelated tracks.
And just to describe the problem in more detail, here is a repost of something I wrote in a different thread:
From a technical point, this bug is caused by buffers that are not thread safe. This means that if you have different threads doing their own thing (like in Sonar), and those different threads all access the same buffer in memory, one thread can change the contents of the buffer while another thread is trying to use that same buffer. The end result is unpredictable, and can be any type of weird, unexpected behavior including things like corrupted data (stuck notes) and random crashes.
I have carefully looked at the memory that Sonar uses when it sends a MIDI event to a plugin. I noticed that even if there is just one MIDI event, the memory buffer is clearly allocated to be able to contain many events at the same time. This seems to imply that they don't allocate the memory specifically for each event, but re-use the same memory over and over. That makes sense since if you want fast performance, you don't want to re-allocate the memory over and over. But this also seems to imply that the buffer can potentially be used by other threads, when they should have allocated such a buffer for each thread, as opposed to re-using the same buffer between multiple threads. That is a big no-no in a multi-threaded app. You can actually re-use the same buffer in a multi-threaded app if you use a monitor/lock that prevents multiple threads from accessing the same memory at the same time. In such a case, just before a thread wants to use the shared memory, it acquires the lock. If a different thread tries to do the same thing while the first thread still has the lock, the second thread will become blocked until the first thread releases the lock, allowing the second thread to wake up and acquire the lock. These are all standard multi-threaded programming techniques.
But in the case of Sonar, I did the following test: In my test plugin, when I receive a MIDI event, I make a local copy of the contents of the buffer that Sonar presents to me. At the end of the same function, I compare the local values to that of the buffer again. Initially, the values would match as you would expect. What I did then was add just a very small amount of delay from the time after I copied the values, to when I check the values again. What I found was that the values no longer matched what was in the buffer. What happened in this case was that my thread was pre-empted, and a different thread than re-used the same buffer, resulting in the contents of the buffer being altered while my VST was still in the middle of processing the events. This is really a serious bug and should not be happening in a mature product like Sonar. I believe this is the cause of all these weird MIDI related bugs, and possibly even some crashes.
Now if only we can get Cakewalk to start paying attention to this, but so far all of our efforts have been fruitless...