brundlefly

What exactly are you trying to do?

He's trying to get SONAR to distinguish between MIDI events on the same channel arriving from different sources, either by independent physical MIDI ports or MIDI Output from a soft synth.

But SONAR fails to differentiate such sources when recording. It's a bug. It's been verified and reported by a number of users going back at least as far as S7.

I didn't believe it myself when first reported, but I tested it six ways to Sunday, and it's a bonafide SONAR bug.

To the doubters: Test it for yourselves as described here, or in the thread that bvideo linked.

To SilkTone: Don't waste your breath on the doubters who refuse to test it for themselves. 

brundlefly, thanks for your voice of reason. This bug has been driving me up the wall for a long time now (much more than a year, it is just that a year ago I was able to narrow the issue down, hence the web-page I posted at the time). And then to have to spend a lot of time trying to explain the problem to people that just don't want to believe it makes it just so much more unpleasant. There are things I really really want to do in Sonar, but I can't because of this bug. You can't have more than one instance of Catanya, for instance (I think you can use EnergyXT to work around it though, but seriously...). Catanya is a plugin that screams for multiple instances. Every other host can do it, just not Sonar.
 
It is funny, every time this bug comes up, people argue that having crosstalk between the same channels from different ports isn't really a bug. I really wish there was a better way for me to explain it. I think I am not very good at explaining technical details.

It is funny, every time this bug comes up, people argue that having crosstalk between the same channels from different ports isn't really a bug. I really wish there was a better way for me to explain it. I think I am not very good at explaining technical details.

I think there are a number of factors working against you:


1. It's unfathomable that such a basic thing is not working properly in a product as advanced as SONAR, and that it was not readily reproduced by the Bakers and fixed at the first opportunity.


2. There are so many ways to screw up both MIDI and audio signal routing in SONAR and be mistaken about what you're seeing and hearing (or not seeing or hearing as the case may be) that experienced users immediately presume some sort of user error - I was guilty of this myself.


3. The soft synth MIDI Out manifestation of the bug is more complicated with more variables, and consequently even more prone to being attributed to user error.


I also think it's easier for people to understand the issue of physical MIDI Inputs exhibiting "crosstalk" between like channels and then see the soft synth problem as an extension of the same bug. But you have to have two physical MIDI IN ports to test this, and many do not.

Stone House Studios


SilkTone,
Now that I am home, and can pull up Sonar - I get the answer I was looking for originally "Where does the midi output go?"
Of course, now I understand how it is supposed to work according to Cakewalk.
Again, when I jumped in, and began with "Just curious" - that's all there was to it. I was asking a question, not doubting your findings. I completely get that there should not be cross talk between channels - but I did not understand the relationship between the midi out and how it is to be selected as an input. Now I do.
That said, I am going to put it through its paces here this weekend, using a couple of different midi set ups.
I am curious about any relationships (or non) using hard midi ports and USB midi ports.

Brian

Brian,
 
Understood. Sorry if I got a bit testy there. I have been struggling with this issue for a long time, and as brundlefly pointed out, the bug is both simple and complex at the same time, depending on how you look at it. It just doesn't make sense when someone else tries to explain it. And as brundlefly said, people usually assume user error unless they try it out themeselves. 
 
As for your question about hard/USB MIDI ports, I think you will find that there isn't any difference. I have both a USB MIDI controller (PCR-50) as well as feeding an Oxygen 8 into my FA-66 using its hard MIDI port. Both reproduce the bug equally. In fact I used these two MIDI keyboards to reproduce the same bug where the MIDI events bleed into each other's tracks when you record both at the same time. Those are completely different MIDI devices using completely different drivers, so I think that rules out a controller/driver bug.

I'm going to risk the wrath of the Cakewalk gods here, but prior to 8.5.2, MIDI-enabled VSTi bugs were already known issues at Cakewalk.  SilkTone has done several thorough step-by-step reproductions of the problem and I've documented my own experiences numerous times.

What remains to be done is to encourage Cakewalk to view these problems as priorities.  While fixing long-standing bugs doesn't make for particularly exciting marketing copy, it plays heavily in user retention.  My own particular work-around involves subhosting energyXT and using it for all VSTi MIDI tasks.  But while I am committed enough to Sonar's workflow to invest money in a bug workaround, other users may simply choose to move on entirely.  Please let Cakewalk know that you care about this issue.

Crg

I fully beleive it to be a bug. I've experienced it my self even when using different ports and channels for different Midi input. But there is a common feature present in all these instances that seems to be being ignored and that is the fact that there is an OS, computer hardware and a VSTi plugin in the data handling path. How do you rule out which is responsible for the problem?
I suppose it's not too much to expect Sonar to regulate all of these factors, I sincerely wish it did.
In addition to all that, how do you know it's not a flaw in the system of Midi?

This isn't obvious?

The MIDI specification has nothing in it regarding VSTi MIDI implementation.  It predates VSTs by many, many years.  By today's standards, MIDI is quite simplistic.  It designates channels, controllers, timing and note information and very little else.  While MIDI certainly has very dated specifications, pointing the finger there is a bit like blaming the alphabet for a misspelled word.

As for OS and computer hardware, I would simply point to the fact that many other packages handle this scenario with ease and the problem has manifested itself on multiple hardware and OS platforms.

Regarding VSTi MIDI implementation, yes, this absolutely could be a factor...except for the fact that these problems occur identically with multiple MIDI-enabled VST instruments from different manufacturers, including Cakewalk.  However these same instruments work perfectly when circumventing the problem with a subhost, which points to the host itself as the culprit.  (I suspect the reason for the subhost solution is that the subhost is not multithreading the instruments as Sonar is.  But better to single thread just a few MIDI applications rather than all of Sonar.)

The only common link would appear to be Sonar itself.

greysound - "Blaming the alphabet for a misspelled word"  Classic!
 
Brian

greysound

Crg

I fully beleive it to be a bug. I've experienced it my self even when using different ports and channels for different Midi input. But there is a common feature present in all these instances that seems to be being ignored and that is the fact that there is an OS, computer hardware and a VSTi plugin in the data handling path. How do you rule out which is responsible for the problem?
I suppose it's not too much to expect Sonar to regulate all of these factors, I sincerely wish it did.
In addition to all that, how do you know it's not a flaw in the system of Midi?

This isn't obvious?

The MIDI specification has nothing in it regarding VSTi MIDI implementation.  It predates VSTs by many, many years.  By today's standards, MIDI is quite simplistic.  It designates channels, controllers, timing and note information and very little else.  While MIDI certainly has very dated specifications, pointing the finger there is a bit like blaming the alphabet for a misspelled word.

As for OS and computer hardware, I would simply point to the fact that many other packages handle this scenario with ease and the problem has manifested itself on multiple hardware and OS platforms.

Regarding VSTi MIDI implementation, yes, this absolutely could be a factor...except for the fact that these problems occur identically with multiple MIDI-enabled VST instruments from different manufacturers, including Cakewalk.  However these same instruments work perfectly when circumventing the problem with a subhost, which points to the host itself as the culprit.  (I suspect the reason for the subhost solution is that the subhost is not multithreading the instruments as Sonar is.  But better to single thread just a few MIDI applications rather than all of Sonar.)

The only common link would appear to be Sonar itself.

It's not obvious to me. I'm a Midi Idiot. What exactly do mean by a sub host? I did some researching today trying to find a GM2 .ins to, put in my instrument definitions and one of the articles I read stated that it was a common action for Midi to obliterate same note occurences when two different Midi inputs sent the same note data at the same time due to the serial nature of Midi information. I wish I'd have saved the link. I'll see if I can find it again.

SilkTone

Crg
I fully beleive it to be a bug. I've experienced it my self even when using different ports and channels for different Midi input. But there is a common feature present in all these instances that seems to be being ignored and that is the fact that there is an OS, computer hardware and a VSTi plugin in the data handling path. How do you rule out which is responsible for the problem?
I suppose it's not too much to expect Sonar to regulate all of these factors, I sincerely wish it did.
In addition to all that, how do you know it's not a flaw in the system of Midi?

If you read any forum thread that talks about Sonar + Catanya for instance, you will see people bemoan the fact that Sonar can't handle multiple instances of Catanya, while every other host can. You can substitute Catanya with Jamstix, and the exact same propblem occurs, or any other VSTi that is capable of sending MIDI events out.
 
And how do you explain the simple fact that Sonar can't record from two MIDI keyboards at the same time without the two keyboard's events bleeding into each other's tracks? That is as basic MIDI functionality as you can ask from a DAW, yet Sonar is incapable of doing even that. From a technical point, I see no way how such a bug can be in anything other than Sonar.
 
Personally I have seen this on XP, Vista and now Windows 7. I have seen it on every version of Sonar going back to at least Sonar 7, and maybe even earlier. I have also seen it using different MIDI keyboards from different vendors, using different drivers.

Well, I'll tell you about an experience I've had with the Fantom Synth.With going into some long details about voice capacity of the Fantom which is a 128 voice polyphony-16 channel synth.
I recorded a backing track using a large number of channels loaded with Fantom presets that contained generally four voices in various combinations in each loaded instrument. That would encompass a channel 1 instrument driving several other instruments, a bass, drums, strings and string channel driven instruments. Every thing worked as expected when recording or playing the recorded Midi voices through the Fantom.
When I attempted to play a second part on different channels of the Fantom that weren't linked to the original channels while playing the recorded voices through the Fantom, the problem you describe occured. Notes in the recorded backing track material were noticably dimmed or replaced by the new notes I was inputing. The problem was more severe if I used the same notes in the same octave and the exact same note at the exact same time was replaced by the new note in most instances depending on the pressure with which it was applied. Same velocity or higher with the new notes replaced the backing track note through the Fantom. A lower velocity strike on the new notes dimmed the backing track notes.
If I recorded the Midi backing tracks down to an Audio file and muted the Midi backing tracks and played the Audio track, there was no problem with the New Midi note input.
So at this point I can't say if the problem was due to the voice limitation of the Fantom, the data handling characteristics of Midi or Sonar. This problem is so similar to yours I have to narrow it down to the voicing capacity of the Fantom or the data handling of Midi.

Silktone,
  I am now concerned that you might be offering a different bug as a symptom of your original VST midi out bug. If it were me, I would not want Cakewalk to think they had fixed the (likely more complicated) VST out & buffer corruption bug just because they fixed the (very likely simpler) bug of channel interference between ports.
  Bill B.

bvideo


Silktone,
I am now concerned that you might be offering a different bug as a symptom of your original VST midi out bug. If it were me, I would not want Cakewalk to think they had fixed the (likely more complicated) VST out & buffer corruption bug just because they fixed the (very likely simpler) bug of channel interference between ports.
Bill B.

I know what you are saying, but I really believe they are the same bug. The symptoms are the same: If you record from two external keyboards, when you select "external keyboard - Omni", it records all notes from the other keyboard. If you select "external keyboard - Ch. 1", it won't record the other keyboard's notes, but notes you play on one keyboard will be cut short the instant you play the same note on the other keyboard. Now if you substitute a VSTi's output in place of one of the external keyboards, the results are exactly the same. That is why I believe it is the same bug. 
 
But just to be safe (since just like you I thought it could be different bugs), I submitted bug reports for both scenarios. They might test it and determine it is the same bug. On the other hand, if it is two different bugs, they will at least have steps to reproduce both scenarios.

don't stop at one bug

I'm not saying it's unlikely there are no secondary issues. But these three issues all involve what happens with MIDI input. I'm thinking input "corruption" of #1 is due to the VSTi seeing it's own output at the input. Ghost notes and stuck notes may indeed be a different manifestation of the same problem seen with physical ports - different because the VSTi output is seen back at the input much faster and nearer simultaneously in the virtual environment than it is when looped back via physical cables, or from multiple keyboards being played "simultaneously".

BTW, here is another bit of strangeness I found...

If you record from an external MIDI keyboard using "external keyboard - Omni" and outputting to a VSTi MIDI output, the bug only manifests if you have one MIDI input driver enabled. If you have two enabled, then there is no crosstalk, although you will still get notes cut short if you select "external keyboard - Ch. 1". Maybe what happens in this case is that it is appropriating the unused MIDI input driver's buffer to use for the VSTi's output instead of the one that is actually doing the recording (well, appropriating either would be wrong of course).

Ryan Munnis [Cakewalk
]

SilkTone,

Please refrain from attacking Cakewalk Technical Support regarding this issue. Our support representatives have been trying to assist you but have been met with hostility that you "have been trying to get in contact with us for over a year regarding this issue and have yet to hear a reply". As we explained to you in private messages previously, the Cakewalk User Forums are not an official way to get in contact with Cakewalk Technical Support as we do not monitor these forums. Additionally, the Cakewalk Problem Report Form is not an official way to open up a dialog with Cakewalk Technical Support. This is explained directly in the problem report form. Regarding your problem report submissions, I researched several of the ones that you have submitted. Below:

CWBRN-1336 - Status - Submitted to Development
CWBRN-2503 - Status - Closed - Duplicate Entry
CWBRN-2534 - Status - Submitted to Development
CWBRN-2533 - Status - Submitted to Development

Any problem reports that have not had their status changed are still being looked into.

To summarize, we are trying to assist. The issues that are known issues have been submitted to our development team in hopes to address in a future release.

Ryan,
 
How exactly have your support representatives been able to "assist" me? When I called tech support and carefully explained the problem using Catanya as an example, the email response I got back stated "...which means it’s implementation issues with their software [Catanya]".
 
It is great that Cakewalk has finally left the denial stage of this bug - it almost took a whole year after I filed the first report of this problem using your official reporting system. This has nothing to do with the forum.
 
But logging an official bug report didn't do anything. CWBRN-1336 was filed on 2/25/2009, even though the report itself incorrectly states the date as 9/22/2009 (I believe you ported your bug reports to a new database, and the dates got mangled). So what should I have done? The report says "Submitted to Development". That tells me zero about whether it can be reproduced by Cakewalk or any other relevant status. So I filed additional reports with different ways to duplicate the same bug. Can you give me advice of what I should have been doing otherwise seeing as Cakewalk has been denying the problem up until a few days ago?
 
BTW, the "Duplicate Entry" report was an accident on my part. After I submitted the report, I switched to a different tab in the browser. After a while I did a "Refress All" for all tabs, and for some reason your report form re-submitted the exact same report again without me clicking on Submit again (even though it was sitting at the "Thanks for submitting..." page, the one that contains the report number). Yea, so sorry for that one, it wasn't intentional.
 
Honestly, given how difficult it was to get Cakewalk to acknowledge the bug, I think the last thing you can do is blame me for anything...
 
EDIT: BTW, you make it sound as if I logged the exact same thing multiple times. Remember that at the time I filed these reports, Cakewalk was still denying that the bug existed at all. I'll add the titles of the bug reports, showing how they are different ways to reproduce the same bug (and please forgive me for trying to give you multiple ways to reproduce the bug):
 
CWBRN-1336 - Multiple MIDI bugs, all related to VSTi MIDI output
CWBRN-2504 - Bugs related to the "Enable MIDI Output" functionality (this refers back to 1336 and gives additional info on how to reproduce it) 
CWBRN-2534 - Can't record from two MIDI keyboards at the same time
CWBRN-2533 - MIDI notes cut short when a different source sends notes

Ryan

I've got a lot of sympathy for Silktone here. Perhaps you should consider making your defect management somewhat more public.

Consider how Cockos does it, for instance. They provide a specific issue tracker sub-forum and this is what they say

QUOTE

If you need REAPER help, have a performance problem, or are not 100% certain that the unexpected behavior is a bug, please discuss it in the user forum, not here.

Bugs should be specific and reproducible. Feature requests should be clearly described. Very popular feature requests will be automatically marked as elevated, and closed to new posts.

The issue tracker will be actively moderated to try to maintain a high signal to noise ratio. If you want to be counted in support of (or against) a bug report or feature request, please use the yes/no buttons. Only add a comment if you have additional information. Content-free posts will be deleted. Thanks!

UNQUOTE

This provides a clean, moderated and efficient way for users to determine if the problem is a known issue, or to discuss proposed enhancements.

At present it is immensely frustrating for Sonar users who may or may not be experiencing a known issue, and I can entirely understand, as a professional software developer myself, why at times the discussions will become a little fraught.

Now I doubt very much that Reaper's bug count is any less than Sonar's, but they are engaging in a much more coordinated way with their users and you need to seriously think about this.

In an ideal world, your confirmed defect list should be entirely public. This shocks many software companies, who feel that if users knew about all the reported defects, they would not use the software. However, consider that pretty much all open source projects have entirely public defect lists and some of these - Google's Android springs to mind - aren't exactly 'two guys in a garage' kind of affairs. You need to open up here on known issues.  Even Microsoft publishes many of the known issues with its product - not all (I know they maintain a secret internal bug list, having been closely involved with them in the past).

Finally, you really do - admit it! -  have rather a backlog of annoying issues to address. The track template volume level problem I reported, for instance. Also a number of other residual issues with instrument tracks, which are still not entirely bug-free.

I appreciate that fixing bugs doesn't sell new copies of Sonar, but it certainly causes existing users to start thinking about alternatives.

"Consider how Cockos does it, for instance"

Cockos do it like the Chinese- piggybacking on 2 decades of others peoples work and then claiming they are game changers by selling it real cheap.