I can't get sonar to talk to two different midi pianos simultaneously.....

I have an axiom 25 going through a USB port and a midi piano coming in through a sonar/roland UM-3g.  I open up two soft synths.  I set one to one input and the other to the other.  However, only one is active at one time.  If I select all channels, still, only the most recently selected is active.  Is there a way to get each input talking to a different soft synth simultaneously? 
Thanks.

Set Midi Echo to On, on both midi tracks.

TheOrginalGrumpster


Set Midi Echo to On, on both midi tracks.

That's the correct answer except its called Input Echo.

Unfortunately with this configuration you will run into the MIDI crosstalk bug. If you record from two MIDI ports at the same time on two unrelated MIDI tracks, Sonar confuses its internal MIDI buffers and the events from different ports will bleed into each other's tracks.

The "work-around" is to select different MIDI channels within the ports (it should not work this way - each port is supposed to be an isolated set of 16 MIDI channels much like the L and R channels inside a track is isolated from all other L and R channels inside other tracks on an old analog mixer). I put "work-around" in quotes because it only slightly alleviates the problem. MIDI events from unrelated ports will no longer be recorded on the wrong tracks, but they will cut MIDI events on other ports short, or result in hung notes on unrelated channels. For instance if you hold a chord down on the first MIDI keyboard, and play notes on the second keyboard, as soon as you hit the corresponding key on the second keyboard, that note will be cut short (or get stuck) on the first keyboard.

This bug will not be fixed in Sonar X1.

This issue has been reported to CW almost two years ago now. From an email discussion I have had with CW, they have only recently started looking into fixing this. Apparently it appears this issue is more extensive, affecting lots of aspects of Sonar and thus requiring extensive testing.

It was confirmed that it will not be fixed in X1. From the email, it sounded like it might be fixed in the next update, which supposedly is in the near future. I assume this is the first fix that will be released to fix the inevitable new bugs that show up with the redesigned UI (couple of months after initial X1 release?).

This bug is an absolute workflow killer in my case. I rely on VSTis that send MIDI events out, and it is essentially unusable in those cases if you also want to record MIDI from a MIDI keyboard. You have to completely disable all VSTis that send MIDI events out if you want to record onto a MIDI track that is in no way related to any of those VSTis.

Cactus Music


Back in the beginning we had to use a MIDI merge box if you used 2 sources to input MIDI to a computer or sound module. There was a switch to set which source was the midi clock.
Not sure if this is still the same because now you have USB input. The original problem was pertaining to the 5 volts in the MIDI cable becoming 10 volts or something like that.

Well this is the exact problem that MIDI "ports" were supposed to solve. The original MIDI spec only allows for a total of 16 MIDI channels. This is inadequate for a DAW. The idea behind the MIDI port is that each port is a unique set of 16 MIDI channels, and channel 1 in PortA has nothing to do with channel1 in PortB. They are just as isolated from each other as the L channel in track 1 is from the L channel in track 2 on an analog mixing console. Unfortunately something went wrong in Sonar and during recording, channel 1 in PortA bleeds into channel 1 in PortB and vice versa.
 
For the analogy to the analog mixing console, the effect would be if you had a singer on track 1 and a guitar on track 2, then if you recorded both at the same time to a 24-track tape recorder, that each of the recorded tracks on the 24-track would contain both the singer and the guitar. The "work-around" that some people claim should "fix" the issue is effectively to say that you should mute the R channel in track 1, and the L channel in track 2 of the analog mixer. Well, it kinda works around the problem, but what about the rest of the band? Where do they go? How are you going to isolate them?
 
In addition as I mentioned above, in Sonar the "work-around" still causes notes to be cut short or to get stuck, even if your project is simple enough that you can isolate each port's MIDI data to a unique MIDI channel. Not to mention that this creates additional complications if you have keyboards that send data on different MIDI channels (split sections, etc). Also, you can substitute one of the MIDI inputs for a VSTi that sends MIDI data out, and you end up with the same issues. Except in that case all you have to do is try to record from the one MIDI keyboard and you'll find all the MIDI notes from the VSTi output gets recorded onto the keyboard's track. Switch the keyboard MIDI input from OMNI to a specific channel, and the result is that corresponding notes from the VSTi causes the recorded MIDI from the keyboard to be cut short or get stuck, even if those events are on different channels.  Add a second VSTi that sends MIDI out, and Sonar most likely crashes a few seconds after they both start sending MIDI events out. This is a horrible bug with no true work-around if you rely on this sort of configuration.
 
If you want to know more about this, here is a web page where I documented this issue in more detail.

brundlefly

Has this been reported/discussed with them?

 
Ad nauseum. And, yes, it's surprising they have not addressed it. However, in the specific case of using multiple physical keyboards for input, it's easily avoided by running different channels, or only recording input from one keyboard at a time. Only events arriving with the same channel on both ports at the same time will interfere with eachother.
 
 
 

This "work-around" does not solve the problem completely. See my comments about cut-off and hung notes.
 
EDIT: From my experience, if you choose different channels within each port, the only difference is that interference happens less. Every now and then you will still run into notes that mysteriously get cut short or gets hung.