I can understand the USB issue with Windows/Sonar. I can go along with the idea that if the USB hardware is not plugged in and powered up that the "Available Ports" window would be empty. What I don't understand is why Sonar would cause my saved projects to have incorrect output assignments on my tracks. To clarify this statement ..... With everything up and working (PC and USB devices) I can open a series of projects and find incorrect port assignments. I then make the cahnges back my oriiginal assignments and save the project. Until the next glitch, everything is fine each time I open the projects.
I am relieved to find that I am not alone with this issue. Thanks for the responses.

Doug

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

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

Tall order, if you're upgrading your USB.

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=?

+ 10,000 on fixing this, and it can be done.

On my machine, periodically my MOTU Ultralite will fail to initialize (motu issue, not sonar).
So, Sonar doesn't see it and moves midi assignments around. If I don't notice, and save, the project will remain in a funky state EVEN IF I get the Ultralite to initialize the next time, at which point I have re-re-configure to match again. It's move up... save... move down... save...

Very annoying, and on at least one occasion my ignorance to the port movements cost me a great deal of time.

Furthermore, there is some way to make this problem better.
Without meaning to pick on Sonar, or push another product as superior, Ableton Live on my same system doesn't suffer from this, particularly the "oops, I saved the project in a bad midi io state" bit.

Funny, I've almost gotten used to it.
The VERY first thing I do whenever I open my first Sonar project for the day is check the MIDI IO preferences to make sure everything's there, and accounted for, and is in the same spot.

- zevo

"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

As I've said above, this should not be a problem if they programme it not to be. Even though Windows references MIDI ports via a number, and that number can change with configuration, every MIDI port also has a name that Windows can see - that's the name that SONAR displays (not the friendly name). CW just have to write their code so that, rather than saying, "this track is assigned to port 3 so send its output to port 3", it says, "this track is assigned to "Unitor 4" so find out what the port number is for the port called "Unitor 4" and send the output to that port.

However, I'm not a Cakewalk apologist but, to be fair to them, it is a matter of finding the time. A change like this to a commercial software package is a lot more than just shanging a few lines of code. It's about:
- writing a spec,
- having it approved,
- writing some code,
- sending the code for quality control testing,
- testing that it hasn't broken something else,
- making sure it's compatible with the code changes that the other 10 people working on the programme at the same time,
- in-house alpha testing,
- sending it out to beta testers,
- going through the inevitable series out iterations around this loop until you're satisfied it's ready for release,

and probably some more steps that I haven't thought of.

Add to this the fact that it is only one of a huge number of other fixes and enhancements you have on the books, the limited resources at your disposal and the cost benefit analysis of this fix compared with all the others...

It isn't as easy as we'd like to think. I'm sure the people on this forum who have been involved with serious, commercial software developement (as opposed to writing sprogrammes at home by yourself) understand what I'm talking about here.

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.

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? The kinds of processes that you enumerate are there to improve assurance, not to worsen it, aren't they?

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.