Wow! Filed over a year ago, and it will be "looked at in due time"?
Tells me that no one is assigned full time to look at bugs, and that even with such a detailed bug report WITH a solution, Cakewalk does not have the time to look at it.
I filed a bug report at least 6 months ago and received no response. I, however, expected such a non response after years of not fixing bugs and dropping support for synths. This led me to drop the Producer version and consider never updating again, as that will surely add more bugs. I purchased Dim Pro only to have out of tune patches and no support for 64 bit VST. 

I can only suggest that you look to scale back any expectations. This is the world of software, especially DAW's. I believe that the problem has worsened since the Roland acquisition and the emphasis on hardware.
Drum maps and ACT improvements anyone? :)
It is a shame because Sonar has so much to offer.

Yep, Sonar 8 is much better than Sonar 7, which is why I upgraded. Does not have anything to do with bug fixes though, unless you really believe that customers should pay for the privilege of discovering  AND fixing items that don't work! I really hope that CW comes through and does fix a lot of things with 8.5.3.
I have been with Cakewalk since the DOS days, I don't want them to fail. 

Crg

dreamkeeper


Silk - I guess what you found would qualify for a bug, at least part of it. But there's a simple workaround: use different channels.

I haven't checked your own plug-in yet, but from my experience it seems that input "... Omni" is the culprit here, along with possible MIDI feedback to the MIDI plug-in. If I set a synth's MIDI track input to (in my case) "Delta AP MIDI - Omni", it will always record another MIDI generator's channel 1 events. Setting the receiving track to MIDI channel 1 will solve this - despite the MIDI plug-in still sending on the same MIDI channel (but different port). Setting the sender to a different channel than 1 will have the same effect. So this might be a hint for the developers where to go hunting for the bug:

- MIDI tracks set to "[external port] - Omni" receive ALL channel 1 events sent by plug-ins - which they should not.


A general advise of caution to all who want to use "MIDI VSTs": Be absolutely anal about your MIDI routings! Use dedicated channels whenever possible to avoid MIDI feedback. Unfortunately Sonar's MIDI routing presets do NOT* include MIDI-sending synths - only the "real" ports (which includes external virtual ports like Midi-Yoke). In particular NEVER set a MIDI plug's input to "Omni" or the same port as its output port - that should go without saying, but I know how easily mistakes can happen with this. It may be a good idea to uncheck "always echo cuurent MIDI track" in global options and then enable input echo wherever it's needed - and only there.

werner


*) applies to S6 - might have changed in the meantime...

+1

What dreamkeeper suggests as a work-around helps to some extent (unless your "+1" was referring to the second part of his reply). But even if you set the MIDI input from "[external input] - Omni" to "[external input] - Ch. n]", it only partially works around the bug. Try to record MIDI on that channel. You will find that notes are cut short whenever some unrelated VSTi outputs one or more MIDI notes.
 
It should not be like this. When you select "[external input] - Omni", and record on that track, it should only record from that selected external source. Why on earth is it recording every single other MIDI event from completely unrelated VSTis that happen to be sending out MIDI events at the same time?
 
It is amazing that a mature, expensive and supposedly professional product like Sonar can't even get basic MIDI right. My guess is that this bug has been there since they implemented their multithreaded engine. It is a difficult to pinpoint bug and I think people have been experiencing it through the years - weird MIDI behavior problems and crashing problems that always end up being attributed to something else. Most likely to the 3rd-party plugin that had to used at the time would be my guess.

Crg


Maybe I'm missing something in your routing but Omni picks up all channels present from the "external input" whatever that may be. That will include any tracks with Midi data set to that external inputs channels as well as VST's placed in their effects bins with associated inputs and outputs. I just can't get away from the feeling that you are dealing with an incorrect routing issue from my own small experiences in removing extranious data input from Midi channels. That would not qualify it as a bug but rather a workflow issue associated with what you see as a work around rather than a routing requirement.

I think you need to read through the bug description carefully, because this is most certainly not a routing issue. You are correct, when you select "[external input] - MIDI Omni", it should record input from the external input, and only from that input. According to the Help files:
 

(name of MIDI input driver)> (MIDI Omni or MIDI ch 1-16). Choosing this option causes the track to record any MIDI channel coming from the named MIDI interface input driver, unless you choose a particular MIDI channel instead of MIDI Omni. Then the track will only record input that’s on the MIDI channel you chose, from the named input driver.
 

It doesn't say it is also going to record the output from unrelated VSTis, in unrelated tracks, that are routed to other unrelated MIDI tracks, or not even routed at all.
 
In addition, it is a hard case to make that the crashing caused by this (as in the Catanya thread) and the cut short notes during recording are in any way user error. Every single VSTi that can output MIDI notes causes Sonar to crash as soon as you have more than one instance. This is a routing error?
 
 
EDIT: You said: "That will include any tracks with Midi data set to that external inputs channels as well as VST's placed in their effects bins with associated inputs and outputs."
 
I think you might be misunderstanding what is meant with "external input". It means a particular external MIDI source, like for instance a MIDI keyboard. In my case, I choose "PCR 1" as my external source, meaning my PCR-50 keyboard that is attached to my computer. So when I select "PCR 1 - Omni" as my input, it means I want to record MIDI events on all channels coming from my PCR-50. It doesn't mean I also want to record MIDI events floating around the rest of Sonar, like those that VSTis send out, etc. 
 
You might be confusing "external input" with "All Inputs" in this case.

what about this one (not sure if it was mentioned before):
- after setting the fade-in/out curves on one clip, you move to the next clip...if the previous clip is still selected...the curve on the previous clip moves entirely over to the 2nd clips side. Annoying having to tweak it back all the time.

Also, is there any chance we can get some vector style automation curves?? (the ones with the smooth look, like in the VX-64 EQ)

Crg


I'm having bugs-stuck notes-voices also. I can't pin it down to Sonar. Cakewalk knows there's a bug. I'm sure we'd all love to hear some progress reports. In my meager investigations I'm coming more and more to the opinion that the problem is related to fact that there has been no adherance to the GM1 or GM2 by all the device manufacturors.
Every new keyboard-synth-workstation-arranger comes with a new set of extended- rewritten- fantastic set of preset sounds built with multiple voices per sound and they do not operate within the set code of Midi.
Expecting Sonar to interpret all these new variables and tell Midi what to do with them when midi doesn't even know what to do with them is a copout. It's easy to say Sonar is at fault because Sonar is the host. But if you ask me, the midi idiot, it's a lack of correlation between the platforms constructed by all the makers of new and exciting peices of equipment and software. Who's catching up to who at this point?

The MIDI spec is pretty simple and straightforward by today's standards. It has been around for a long time and there are very few areas (if any) where there are still questions about implementation.  I will really be surprised if someone actually manages to implement it wrong at this point.