Amazed

Come on Cakewalk, just fix these simple bugs!!! It really is easy if even I can fix it

Silk,

I'm not certain that throwing down the gauntlet to Cakewalk in a public forum is the fastest way to getting this done. Put yourself in their shoes and let's assume you're right. If they suddenly fix it, how do they look? If they admit the issue first before they fix it, how do they look? If they just deny it and claim you're an idiot, how do they look?

Sometimes the fastest way home is not the most direct :)

Cheers.

 
Yes I understand what you are saying. To be honest, I don't think CW really cares about this and how they might possibly look if they fix/admit/deny this. I am well aware that software has multiple bugs and some of those are really simple or obvious, but it happens and that is why all software needs to go through a QA process that tests even seemingly obvious functionality.
 
But my experience with dealing with Sonar related bugs is not great. I have filed multiple bug reports and none so far have been fixed over the years, even the ones that have been confirmed. No-one from CW ever got in contact with me to get more info on any bug reports I filed. I spent a lot of time on this particular bug report, creating screenshots, creating a Sonar project file, creating a plugin that clearly demonstrates the bug, including the source code for the plugin, etc. Of course I didn't have to do any of it, but I thought at the time I was doing a good thing. But I won't bother doing anything like that again. I basically had to beg them give me a status update on the reported bug, and when I finally got some feedback, it was basically just a boilerplate "we have received the bug report and will be looking into it". That bug has been confirmed by CW but there have been no fix in later releases. I might as well be reporting these bugs to a wall, I'll get about equal results.
 
So if I seem to "throw down the gauntlet to CW", it is merely my frustration related to this ongoing attempt to get them to fix any of the bugs I have been reporting. I really like Sonar and it is because I want it to become a better product that I report the bugs in the first place.

Amazed

I'm not certain that throwing down the gauntlet to Cakewalk in a public forum is the fastest way to getting this done. Put yourself in their shoes and let's assume you're right. If they suddenly fix it, how do they look?

I don't know about others but to me: Smart. Willing to listen. Humble. Willing to learn. Open minded. Quick to fix a now known problem with a known solution. Need I go on? :)

If they admit the issue first before they fix it, how do they look?

See above except for the last qualifier. At least, it depends when the next patch is released.

If they just deny it and claim you're an idiot, how do they look?

If it is ever found out that they are wrong and SilkTone is right they will have done irreparable damage to their own and Cakewalk's reputation.

Sometimes the fastest way home is not the most direct :)

And sometimes it is. :) After long complaining in public on this forum about the lack of time subdivisions in menus, Ron Kuper at some point posted a message saying he had fixed it and it would be included in the next update. He did it as a result of my complaining. Next update the new subdivisions had been added. Hurray hurray! (Not once did I think less of Ron Kuper for doing this. On the contrary).

UnderTow

Susan G


Hi UnderTow-

He did it as a result of my complaining.

Not trying to be argumentative, but did Ron tell you that (privately or in a post)?

Yes and I quote "I've already coded a fix for this for SONAR 6. The 64th note resolution has been that way forever, so chalk it up to inertia.  As you pointed out it was a trivial change."

(I find the last sentence interesting considering what all the naysayers were saying on the forum at the time). The reason I feel ok with quoting Ron's correspondence with me is that he also responded publicly on the forum saying pretty much the same thing.

I think suggesting that any one User complaining about the lack of a feature or pointing out a bug loudly and often enough will get results isn't borne out by the facts.

It is but this point does need to be nuanced! In SilkTone's case, the research has been done. The effort has been made to contact Cakewalk through regular channels etc etc. In my case it really was an incredibly trivial thing to fix and I had also gone through all the official channels first.

I am not suggesting that everyone start loudly campaigning for their particular wish for the next version of Sonar. The regular communication channels are still the best way to request any new features or bug fixes.

UnderTow

Thanks for sharing!

I've deleted any plugins that caused these types of problems. (Often demos that I didn't purchase partly due to gfx issues). Next time I will be sure to run your application to see if it helps.

UnderTow

Hi UnderTow-

Okay, understood. Thanks!

-Susan

SONARtist


SilkTone : I would like to have your advice.  This may be OT here, but if so, please say so and I'll start a new thread.
After reading thru' your other bug report concerning MIDI, I am wondering if what you have found is the reason that some softsynths continue playing already-triggered notes when the transport is stopped.

In particular, and in my case, Waldorf's LARGO is displaying some of the symptoms you describe.  It should be acknowledged that LARGO has no such issues with any other host except SONAR, as reported by some posts.  At least one other softsynth is affected (the name escapes me, but AMAZED had reported it not so long ago).

What do you think ?
 
Edit:  Added AMAZED's comment here :-
I have experienced this quite recently with Gforce Virtual String Machine. When you stop the sequence a few notes are left stuck. There are certainly no events in the list that I can see that would cause this.
 

It is possible that the problems you see could be caused by the bug as described here. The problem is that that particular bug could cause a wide range of seemingly unrelated problems, so it is difficult to know for sure. These are the kinds of issues I have seen that I believe are directly related to that bug:

1. When you use a VSTi that has 'Enable MIDI Output' enabled and it is sending MIDI notes out, other unrelated tracks that are recording MIDI from an external controller will also record MIDI notes that the VSTi is sending out. Note that in this case the unrelated track is clearly set to record only from the external controller.
2. Even if you can use some of the work-arounds to prevent these stray MIDI notes from being recorded into the wrong tracks (like using a specific channel of the controller as opposed to omni on the controller), you can still experience weird behavior like notes you are recording mysteriously being cut short, etc.
3. If you use a VSTi that processes/creates MIDI notes, those MIDI notes it sends out can often become stuck.

Now I have a suspicion that this is also a possible cause for unexplained crashes. I can't confirm this but this particular type of bug can cause a range of bad things to happen including crashes.
 
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.
 
But the problem is, as I said, getting Cakewalk to even listen to anyone. Yes sure I come across as annoyed, rude, arrogant, whatever. It is because I tried to get this point across to CW but I'm being ignored pretty much. The fact that they allow this kind of serious bugs to exist in Sonar is just troubling to me. As I said I really like using Sonar (as a hobby) but I am glad I don't rely on it for a living because if I knew about these kinds of bugs I would be concerned about having a paying client watch over my shoulder while I use Sonar. Yes, that is harsh but if CW was more open to discuss this kind of possible bugs with lowly people like me, then I would have a more positive attitude towards all of this.  As is all I am to them is just someone rambling on about some imaginary bugs in Sonar.
 
So to answer your question: Yes, it is very possible that this could be the cause of the stuck notes, but it is hard to know for sure.

"SilkTone : I would like to have your advice.  This may be OT here, but if so, please say so and I'll start a new thread.
    After reading thru' your other bug report concerning MIDI, I am wondering if what you have found is the reason that some softsynths continue playing already-triggered notes when the transport is stopped.

    In particular, and in my case, Waldorf's LARGO is displaying some of the symptoms you describe.  It should be acknowledged that LARGO has no such issues with any other host except SONAR, as reported by some posts.  At least one other softsynth is affected (the name escapes me, but AMAZED had reported it not so long ago).

    What do you think ?
    
    Edit:  Added AMAZED's comment here :-
    I have experienced this quite recently with Gforce Virtual String Machine. When you stop the sequence a few notes are left stuck. There are certainly no events in the list that I can see that would cause this. "

SONARist,

I believe this is the same issue that Sample-Modeling addresses in the maunal for The Trumpet sample instrument for Kontakt:


   " Tip: Sonar users might experience hanging notes upon stopping the playback. This is due
    to the fact that Sonar sends an “All-Notes-Off” command when the Stop button is pressed.
    The problem can be easily solved by checking the box “Accept all notes off/ all sounds off”
    under “Instrument Options -> Controller”, as shown below. "



Not sure how you change this for LARGO or the G-force instrument.



Mark

SONARtist


SilkTone, many thanks for your great explanation.  And I do understand your logic, although I am not a programmer any longer (I used to be, but it was ERP apps and not in Windows :-)

I am wondering if I should download your test files and apply them to my environment and see what happens.  I use external MIDI controllers (MOTU) / keyboards to trigger the softsynth so I think I should be able to see what's happening with "note-on/note-off" etc.  Will give it a try.

Correct me if I am wrong, but your utility is getting "in between" the (recordable) MIDI track and the VSTi which ultimately produces the sound.

Reading all your posts, I have a very high regard for your programming and debugging skills, and it is a shame that CW is not responding in a favorable manner.  Thx again.

Note that the MIDI related bug described in the linked page is different from that originally discussed in this thread. We are currently discussing two completely different bugs so just keep that in mind. You should not use the utility I provided in an attempt to fix the MIDI related bugs. That utility is purely meant to address the issues with some plugins having problems drawing properly to the screen. As far as I know there would be no way to address the MIDI related bugs with an external utility. Only CW can fix that.
 
As far as what exactly the external utility does: It scans all open windows and searches for those that have the typical Sonar plugin signature. These include standard Sonar plugin windows, BitBridge windows, jBridge windows and V-Vocal windows. Once it finds one, it traverses the windows contained within that window and sets each one's flags to the proper values. Once that is done, it doesn't do anything else, so it gets out of the way at that point. Once it sets the flags, all drawing in the plugin windows start working properly and that is why it no longer needs to do anything else.
 
When you press the Fix Windows button in the utility, it will do one scan at that instance, so if you open a new window, you will need to press the button again. On the other hand, if you enable the Auto Fix option in the utility, it will re-scan every 2 seconds so that if you open a new plugin window, it will get fixed at the next scan.

SONARtist


SilkTone >> Note that the MIDI related bug described in the linked page is different from that originally discussed in this thread. We are currently discussing two completely different bugs so just keep that in mind. You should not use the utility I provided in an attempt to fix the MIDI related bugs. That utility is purely meant to address the issues with some plugins having problems drawing properly to the screen. As far as I know there would be no way to address the MIDI related bugs with an external utility. Only CW can fix that.

I should have been clearer ... when I said "test files" I actually meant your MIDI test files, not the utility which is the main topic of this thread.  My bad, sorry.  And apologies to everyone for hijacking this thread.  I will now disappear :-)

Ah, I see what you mean. Sorry, I misunderstood. In that case you should not use any of the files linked to in the MIDI bug, since it won't help you.  What I did there was I created the most straight-forward VSTi plugin I could that would demonstrate the bug in Sonar. So its purpose is to expose the bug, not provide a way to work around it.
 
The reason I did that was because there is no way to reproduce the MIDI bug with anything that ships with Sonar. So far I have been unable to find any VSTi plugin that ships with Sonar that passes through or creates MIDI notes that you can use via the "Enable MIDI Output" functionaly. This means that whenever this bug reproduces, there is always a 3rd-party plugin involved, meaning CW can always say it must be a bug in the 3rd party plugin. As such, I decided to create the most simple plugin I can that passes through the MIDI data so that the bug can be demonstrated. I also provided the source code so that CW, or anybody else for that matter, can verify that I didn't do anything weird in the plugin that is causing the bug.
 
On the other hand the utility linked in this thread that deals with the incorrect window flags can very well be used to fix that problem as described in one of my posts above.

But the problem is, as I said, getting Cakewalk to even listen to anyone. Yes sure I come across as annoyed, rude, arrogant, whatever. It is because I tried to get this point across to CW but I'm being ignored pretty much. The fact that they allow this kind of serious bugs to exist in Sonar is just troubling to me. As I said I really like using Sonar (as a hobby) but I am glad I don't rely on it for a living because if I knew about these kinds of bugs I would be concerned about having a paying client watch over my shoulder while I use Sonar. Yes, that is harsh but if CW was more open to discuss this kind of possible bugs with lowly people like me, then I would have a more positive attitude towards all of this. As is all I am to them is just someone rambling on about some imaginary bugs in Sonar.

I didn't see anything you said as rude or arrogant, perhaps just frustrated - and you have right to be. Some of these bugs can be found by any user during casual use within a few minutes, and for that reason I have at times questioned the effectiveness of the beta testing program - around here all that got me was a flame war instead of a level discussion. You have done some serious investigation, and found interesting results, and at the very least I should think you could get some type of response back from your bug report submissions. I can hardly blame you for posting here after not getting one.

I am also confused at the reaction some had to your initial post. You have posted your findings of something that appears to fix a problem without an obvious side effect, and get criticized for it. I guess just like with sports (never understood this personally) people defend what they 'think' they are a part of - around here its the same group all the time doing this. The only people who should have a right to that type of defensive response should be actual Cakewalk employees, and even then I should hope they would respond openly instead of defensively - some of the time they do. To the rest of the forumites...what are you defending for? Team Cakewalk is doing just fine on the field without you.

Lastly, none of us knows what talent Cakewalk has in the programming department. They might be veteran software engineers, or they might have some rookie programmers, or maybe they have veteran programmers who cannot also engineer (plenty of programmers with years of experience have terrible design habits while believing themselves geniuses). Or maybe their legacy code base is such a mess that most of the bugs are a result of developing around it and trying to replace it with better code. None of us really knows, and assuming either way is futile. Large companies can and do have incompetent people in important positions (not saying that is the case here) just as easily as they have experts so we cannot assume to know just because we like the product. Having said all that, I personally think it is likely that Cakewalk does employee some very bright minds, but I have seen some interesting bugs make it to the product that leave room for improvement in their process.

D.

Thanks TheSteven.  I have already contacted the PlugIn developer with the issue.  Now back to the proper thread ...