Although it should not be this way, I find I have to restart my PC after plugging in a USB keyboard, or it will not be recognized. Just restarting Sonar does not work.
 
 

jjdubs
 I was able to fool my system into allowing both Oxy49s to be used. 
 

Would love to hear how. it would help other users trying to do the same.

Well, it helped that the two Oxygen 49 keyboards were NOT identical. When I first hooked up the newer Oxy49 along with the Oxy49 Blue, only the newer one would work.
 
(Now that I think about it, perhaps the "delete TTSSEQ.ini" trick may have worked then, too.)
 
Anywho, I checked the M-Audio web site and it turned out that the Oxy49Blue did have a legacy driver. So though the older Oxy49Blue was also class compliant, I use it with its driver so the computer and Sonar saw them as the two different machines that they are. 
 
It's good to know that there could be issues so as not to buy two identical units. Perhaps, for instance, an Oxy49 and Oxy61 might work OK together. I dunno. 
 
John
 

Awesome that you got it fixed. Regarding the identical controller issue, I highly suspect this is associated with the driver dll files not being able to have multiple instances created. Many programs are this way, and Windows will simply switch to the original instance if another is called. I am not sure how Win10 handles this situation, since most people report that Windows is seeing both controllers (like in Bob's case). There are a lot of things under the hood with how these are connected that is not obvious to the end user.

I prefer simple explanations, when there is no prove they are "too simple". Not only inside Sonar, but also inside mentioned INI files, controllers are mentioned by port names. Identical names can trigger the problem. Different driver normally expose different name.
 
After previous discussion in another thread, I have tried to find a method to give different name to device. I have managed to show Sonar other name... But the change was reverted after reboot and I can not test myself that it works for the purpose (I do not have identical devices).
 

OK. The "TTSSEQ.ini" thing works BUT I have to do it each time I reboot the computer. Hmmmm
 
John

OK, just checked. It's each time I reboot Sonar Pro.
 
John
 
 

Well... you can try to "lock" it (make the file read only), but I do not think that is going to help.
You can also "lock" broken (empty) file, you will have to select devices every time, but at least you do not have to delete the file first
 
You can upload it so we can have a look. Who knows, may be we get some ideas...
 
And please submit bug report. You are not alone with the wish Cakewalk finally fix MIDI device jumping/breaking/shifting/etc. In some recent version they in fact have managed to make it worse (while it never was even close to perfect...).

Here's my  TTSSEQ.ini file contents after Sonar re-creates it and the system is working:
 
[MIDI Input Devices]
0=nanoPAD 1 PAD
1=Oxygen 49
2=Oxygen 8 v2 MIDI In
3=Oxygen 49 MIDI In
MaxInPort=3
[MIDI Output Devices]
MaxOutPort=-1
[MIDI Echo Devices]
MaxEchoPort=-1

Are you running Sonar Pro with Administrator privileges?  Some systems run this way.