MIDI pain in ass - Still an issue in X3E

Same here. I'd like to know how/if I can lock the sequence of all the MIDI input devices so that they don't get changed around and mess up projects.

Also, if one control surface (e.g. A-800 PRO) is not switched on, you will have to reassign it in the preferences next time you use Sonar ...

Hmmm, so you are sugesting to buy one more device and disable all MIDI ports on the rest of the gear? Not quite what I'm inclined to do ...

I'd be happy if it remembered the last sequence it had all devices loaded and would stick to it (much like it does for the ASIO audio IN OUT)

CakeAlexS


Hi
 
Is there any way I can stop Sonar X2a from auto detecting USB MIDI devices? i.e freeze the current configuration.
When MIDI device get switched off and on Sonar seems to love changing all the tracks MIDI channels settings for me. I'd rather it just stayed as it is, even when a MIDI device gets unplugged. And ideally no prompt asking me what to do when MIDI device gets unplugged or switched on, just stay as it is. MIDI hardly ever changes in my studio.
 
Cheers
 
Alex

+1. This is a big bug-bear for me too. I have several devices including synths and controllers that connect directly by usb, as well as usb midi ports (MOTU traveller and a MidiSport 2x2) and often the port numbers often get re-ordered for no apparent reason. Painful when using templates and custom midi inputs. I think it's more of a hardware issue than a software one though.

The issue is with the Windows Audio Endpoint Builder Service, and not Sonar.

On every start-up, the WAEB service iterates through the system's audio devices in PCI/USB order (The root USB hubs are located on the PCI bus). These devices are then listed in that order by the WAEB service. If you do not change ports or power cycle hardware, the order will remain the same.

Shutting a device off, the WAEB service removes it from the device list.
Turning it back on, the WAEB sticks it at the end of the device list.
Sonar listens for when the list changes and re-reads it.

Since the service doesn't create an identifier for a device that stays the same between restarts, Sonar cannot know if it had seen the device some time before, to put it back into the original order.

The second problem is that a piece of hardware can have several devices associated with it (audio, several midi ports, etc). Depending on how the drivers are written, there may be no consistent way the WAEB service orders them when you power cycle a device on a running system.

That being said, you can cheat by restarting the Windows Audio Service (it depends on the WAEB) and the WAEB. This will force Windows to rescan all the multimedia devices on your system, ordering them by PCI/USB address as it does when the system boots.

CakeAlexS


Is there any way I can stop Sonar X2a from auto detecting USB MIDI devices? i.e freeze the current configuration.
When MIDI device get switched off and on Sonar seems to love changing all the tracks MIDI channels settings for me. I'd rather it just stayed as it is, even when a MIDI device gets unplugged. And ideally no prompt asking me what to do when MIDI device gets unplugged or switched on, just stay as it is. MIDI hardly ever changes in my studio. 
  
Alex

The only way I have found to beat this behavior is to ensure that all my MIDI devices are turned on before starting Sonar.  I use a Midisport 8x8, which was one suggestion, but if I forget to turn it on before Sonar starts, then my MIDI configuration ends up hosed, so that is not necessarily the answer.  It's a royal pain, for sure, but if you just remember to switch everything MIDI on before you start Sonar, then you are golden.

It would be nice to have a way to simple disable MIDI functionality, for example, inside the Preferences area. I never use MIDI, so anything Sonar does regarding MIDI would be wasted CPU cycles to me. 

Paul P:js516, do you know if the audio devices are rescanned after waking from sleep or hibernate ?

  They're only scanned when the endpoint service starts up (boot time, or restarting the service itself). The service isn't aware of hibernation or sleep. As far as it's concerned, it had too much to drink, blacked out, and has a hole in its memory after waking up with a hangover. :D

"Old post". Bumping this, I haven't tested it in X3 however. Somebody recently posted something similar to this before I lost the darn post.
 
(This thread, getting takelanes to be optimal , somebody had issue with MIDI implementation (TBC), and 64 bit precision. Guess they are the most pressing issues for me now).

So I'm not the only one with this problem, my setup inclueds...  Octa-Capture - PCR-500 Key's and a Alesis Control Pad and unless they are all turned on before launching X2 and plugged in the same way, then it's a nightmare! 

SuperG
 
Vegas - all the tracks you can muster. Just consider the video functionality a freebee.

I purchased Sonar X1 because Vegas will not do what I need for it to do as far as audio production.
I do video production too, and use Vegas Pro 11 64 bit (I have VP 12 but it doesn't seem to work as well for me as 11).  In Vegas 11 or 12 you can not solo a bus.  If you do, it will solo that bus from the other buses...but will also play any track in the TV that isn't sent to a bus.  So...bus soloing does not work.  It even states in the manual that this is how it is supposed to work now.  I also have Vegas 8 and you can solo a bus with that version.
 
But you are correct...Vegas does not support midi routing :) .
 
But...to me it would be like going from a new Porsche to a 1972 Ford Pinto.

Yup that is the behaviour beepster, everything is fine if you remember to turn things on first. Otherwise the best thing to do (for me) is to turn everything on and restart Sonar. That is the workaround. So looking at #19 we can deduct that only USB MIDI is effected. Also I understand this is a windows feature but there has to be a better way for Sonar to have a memory (or freeze a memory) of MIDI track/channel configuration.

windows version of Harrison mixbus is a daw that has no midi

hmm... but how could it do that if it's windows that is rearranging/dropping things? Wouldn't it have to send a phony MIDI connection signal to the OS or something?
 
With saving I'm sure your set up and usage is far more complex than mine but I save stuff with the devices turned off and it seems to route things properly when I fire them up again. But that of course is shutting down Sonar then restarting again.
 
IDK... I'm probably not understanding what's going on... as usual. Hope you get it figured out one way or the other.

> hmm... but how could it do that if it's windows that is rearranging/dropping things?

Sonar would keep a table of USB MIDI devices which would be compared everytime a USB MIDI device goes online (or offline). The track that has USB MIDI devices assigned could be flagged (automatically by default) to automatically change to a particular MIDI device when it starts up.
 
So you are saying if you boot up a project with a MIDI device turned off, then save, then close sonar, then turn on MIDI device, then open project it won't be rerouted?
 
> change the attributes of ctrlsurface.dat and ttsseq.ini to read-only.

That's a very interesting idea, I will investigate. Anyway I'm hoping Cake can introduce functionality whereby file attributes do not need to be changed.

CakeAlexS
 
Sonar would keep a table of USB MIDI devices which would be compared everytime a USB MIDI device goes online (or offline). The track that has USB MIDI devices assigned could be flagged (automatically by default) to automatically change to a particular MIDI device when it starts up.

I guess I figured it already did something like that. This is the first time I've heard of the problem. I'll have to check it out.
 

So you are saying if you boot up a project with a MIDI device turned off, then save, then close sonar, then turn on MIDI device, then open project it won't be rerouted?

 
Not that I've noticed and I'm thinking through some of the projects I've done and I've definitely saved with the unit turned off many times and it was always ready to go again. However I'm not sure whether I've done it on a project where I was switching back and forth between devices. Like if I used the pK on a drum track, saved/closed, turned off the pK, reopened with the Oxygen, saved/closed, turned off the Oxygen then switched back to the pK. I mean I THINK I've done that but I can't remember specifically. I haven't really used the pK that much yet. I will be though so I guess I'll see.
 
Now does this affect devices connected VIA din through the interface as well? Seems unlikely but I'm going to be using my DX-7 as a controller soon. I just like to have these types of potential problems somewhere in the back of my brain so I don't freak out... because I'm easily freaked out. lol