Locking MIDI port assignments

I respectfully re-submit this.

Thanks,

Doug

Sorry if this is dumb question.

Do you mean assign an instrument to a certain hardware midi port?

I believe he's talking about midi "routing I/O" assignments. It actually happens quite often that Sonar will lose those. I used to think it was just upon a new install or update but it's happened to me at other times as well. I have a master template that has all my most used softsynths along with a click track and multiple midi and audio tracks. I also have three outboard hardware sound generators (my controller, an Alesis QS8 and a Roland TD10 and a Korg Wavestation SR) that are set on different and various midi channels. What happens I think is that any time you make a change or add a new midi device in your Global settings you run the risk of having all your midi routing changed as well. While there may be a "quick fix" (and if there is, somone please clue me in to it) I generally just go back and change all my individual tracks back one at a time and then resave the template or project. It is a PITA ain't it?

This is a biggie for me, too! I've reported it before, and made sure it has nothing to do with turning on all my hardware first. It's a *huge* PITN! I've suggested using "placeholders" the way they do for missing synths or FX if SONAR can't detect the MIDI In/Out for whatever reason. To me, this would be far preferable to assigning them randomly.

-Susan

This is a total PITA for me too.

My problem is that I added a new USB card to my system, and windows decided to reinstall the USB devices. Now they show up under both their old and new names, but Sonar reassigns them at random every umpteenth boot. Maddening, and it could mean I need to reinstall first Sonar, and then the entire OS with a bit of luck - and I *can't* at this point in time, since I'm waiting for a defective install disk to be replaced for a program that I *need* for work, on that machine. Cute.

quote:

ORIGINAL: Susan G

It's a *huge* PITN!



Susan, you're so polite.

If the N were for Nuts it wouldn't be so polite, but that would seem an unlikely choice of expletive for Susan, however I agree with the sentiment nonetheless. It is tedious in the extreme to open an old project (old meaning one that pre-dates the last significant reshuffle of MIDI kit) to find that tracks are assigned to completely different instrument definitions and then to have to figure out what the track really relates to. I've often hoped that something positive might arise out of the serendipity but it hasn't yet.

The other aspect to this relates to ACT. If I start Sonar without my USB keyboard connected, Sonar reassigns the ACT MIDI Controller to another MIDI device, but does not reassign it in a later session when the USB keyboard is available.

Another irritant is that Sonar does not recognise USB MIDI devices that are started after Sonar. Project 5 however does so, so this is clearly not a technology related limitation.

Usually once I have corrected the OS error

Don't you think I tried removing each and every single USB audio device manually, before posting? Several times, even? As I said, I did look where it got this info from, but to no avail.

but Sonar should be able to recognise that a specific MIDI port has become available again

Sorry not trying to be difficult, but I am not sure how Sonar can tell if a midi port has become free. Unless you are refering to active sensing which not all midi hardware devices support.

Don't you think I tried removing each and every single USB audio device manually, before posting? Several times, even? As I said, I did look where it got this info from, but to no avail.

Yes I do belive that is what you tried to do. Again trying to full understand and not questioning your approach. Just a thought did you remove all registry entries as well. We all are aware of how badly XP/MS handles USB.

I am honstly trying to understand do other DAW products know what midi hardware is plugged in to which port on startup??? assuming that the PC/Mac (Am I allowd to use that word here) is the last thing turned on in the chain.

Unless you are referring to active sensing which not all midi hardware devices support.

No, I am not - far too tricky that! I am simply talking about the situation where, say, a USB MIDI port has been disconnected and later is reconnected, making it available again. Sonar can see whether the port is available or not and should assume that the corresponding hardware is available or not. The present behaviour forces the ACT MIDI Controller on to the next available port (of course, regardless of what is actually physically connected to that port) and as long as that port remains available (i.e. known to the OS) the ACT MIDI Controller remains there. Even if the "correct" MIDI port is made available again. This has almost made me give up attempting to use ACT.

Like too many things out of the CW stables recently, it is not ready for the big time.

But, anyway, I am now diverting attention away from OP's original issue, when all I intended was to show solidarity

All I can say is...

If you must have more than one USB midi device - move the most likely to be absent to the bottom of Sonars midi port list. In my experience, Sonar does not reassign ports above the missing device. Never put removable midi devices above any fixed (pci, gameport) ports you may have.

Never plug a usb device into any other usb port than the one you first installed it on.

If the manufacturer provides a driver - use it, even though the generic Windows driver works. At least it will get a unique device name that way.

Don't expect either Sonar or Windows to be able to reliably tell the difference between more than one device that use the same driver (USB audio device). The only way I can think of resolving this is if each USB device had a unique ID written into it (like the serial in every NIC) and that the o/s and applications supported this means of identification.

Don't expect several identical USB midi controllers to keep their widget assignments in your software - if Windows plug&play changes the device ID's Sonar is either going to find one or more missing or their functions might be swapped.

Try to use only one usb midi device. eg -if your USB keyboard controller also has 5pin DIN midi out, use the DIN into a multiport usb midi interface together with your other midi gear.

Fun isn't it?

Jim

ORIGINAL: Wookiee

The problem as I see it is two fold or even more and not alltogether in Sonar or Cakewalks control.

1. Sonar has no way of knowing how we plug up our hardware. Consequently, and not wishing to appear confrontationall, I am not sure how this stops the product from being used in a professional environment after all it is not psychic. Unless I missed that in the feature list.
2. Windows can play silly b's with USB related hardware.

Personally I have never had Sonar or its predessors loose Midi port assignment unless the OS has screwed up first. i.e. it did not find either my midisport 8x8 or my MOTU Midi express XT. Or I decided to change what ports my hardware uses. Usually once I have corrected the OS error or my own stupidity Sonar continues as last set in the Master.ins and INSTRMAP.INI. WHich one could argue are lookup tables.

With regards to loosing softsynth assignments then that probably is a Sonar problem, but as this has not happened to me I am unable to coment with any real authority.

It's easy to understand. Try unplugging something like a Motif from IT"S USB (say you need it for a live gig)and start Sonar. I hope you don't have a lot of instrument assignments because you really just screwed up Sonar's port assignments.

http://forum.cakewalk.com/tm.asp?m=1201610&mpage=1&key=?

"Tall order, if you're upgrading your USB. "
If you do that, you might as well trash your Sonar settings and start again - and having done that, keep to the same usb ports.

As long as your sequencer is looking for a device by whatever name or bus ID the o/s has provided, it is never going to get it right. It would have to discover the device by an indelible and unique identifier in that device instead, then it wouldn't matter where is was plugged in.

It's not that different from the old problem with drive letters. We can in this case give the drive a unique identifier using the volume label, but if the system only uses the drive letter, and can arbritarily exchange this on every startup (this does happen if you use mulitple external drives and don't keep them plugged in and switched on before startup), then you can expect your shortcuts to the files to become invalid.

Jim

I get this problem often.
AND I NEVER UNPLUG ANYTHING!

My Motu MTPAV USB and my BehringerBCR2000 USB get dropped by Sonar regularly and ports assigned in projects get redistributed (presumably to the next port on the list).
Correcting everything every time is a total PITA.

Why would Sonar drop these ports? They are powered ON before Sonar starts, they are plugged into the USB sockets they've always been plugged into.

My HDSP9632 PCI never gets dropped.

ORIGINAL: ChristopherM

It isn't as easy as we'd like to think.

Nothing ever is ... and your point is what? That we have paid for premium professional grade software, but that we have to accept that the vendor finds it too difficult to get it right?

No, just that it's a shortcoming of the software but one of many, as with all other software. And, seriously, let's get the notion of paying for "premium professional grade software" into perspective. You paid a few hundred dollars, in the world of software that's chicken feed. I've seen software that clients have paid multi-million dollars for that had so many bugs it was abandoned (and, no, the software vendors didn't lose money on the deal). That's not a justification for not getting what you want but the realities are:
- no-one can expect bug free software at any price (there is no such thing), but certainly not for a few hundred dollars,
- no matter how many bugs are fixed there will always be more so we will never be satisified,
- there are so many bugs to be fixed in something as complex as a DAW (or an OS) that the particular bug that bothers you may or may not be fixed in a hurry,
- CW, compared to many other vendors, do a lot of free big fixes but they also have to devote time/resources to new features to keep up with/ahead of the pack and that necessarily introduces new bugs,
- past history has shown that they do take note of feedback from these forums but knowing something is wrong is not the same as fixing it so it can conceivably be years between a bug being reported and being fixed because they have to prioritise,

No matter what you may think, we simpy haven't paid them nearly enough money to be able to address all if the issues (bugs, feature requests...) raised in this forum because the work/resources required to do that would be enormous. We can't isolate one pet bug and say, "it wouldn't be so hard to fix that" because there will always be other users with different priorities complaining that the resources aren't going into fixing the right bugs. Add to that the users who just can't understand that the concept of bug-free software is a nonsensical fantasy.

I've been complaing about the MIDI port bug for nearly 2 years and,one day, I think it will be fixed. But seriously, it's an inconvenince, not a show stopper. And to anyone who thinks that for what they've paid they shouldn't have to put up with such an inconvenience - I'm afraid you're viewpoint is an economic nonsense.