gswitz

200bpm
By changing the default to 24/96 I can switch between projects without this problem.  So I guess the bug here is inability to switch between different rates without dropping outputs??  

Yes, I think that the problem is related to the control of your interface and the switching of it from one sample rate to another. Something is blocking the switch between the Sample Rates. On my computer, in the system tray at the bottom right, there is an RME Driver Icon you can open to see what RME reports the current Sample Rate to be. Be warned, having this open may block Sonar from changing the rate. This is what I was describing with RME DigiCheck (which you should download if you haven't).
http://www.rme-audio.de/en_downloads.php?page=content/downloads/en_downloads_driver&subpage=content/downloads/en_downloads_digicheck
 
So, something is blocking Sonar for making the switch on your computer. I'm not positive what it is. When Sonar detects that there is no ASIO Interface matching the project, it is clearing your stuff out. That's your prob. So, what is blocking Sonar from altering it. That's why I kept asking about ASIO. I was wondering if a wrong driver setting might block it. Having another sound program open locking the device would do it too. That was what @ was trying to tell you.
 
Do you follow the problem? Ask if you are confused. It's a confusing concept. Basically, at one moment, Sonar recognizes a device at 96 it can use, and then at the next moment it doesn't.
 
Again, I'm travelling and have only Linux with me. When I'm home I'll test with Sonar. It's possible that the 44.1 project you open somehow isn't all the way closed or for some reason hasn't released your device.
 
Here's another thing to try (something I might do),
1. Open your 96 Proj. - don't close it
2. Create your 44.1 Proj. - don't close it
3. (Without closing either project) Alt+W and choose to switch between the projects. Switch back
 
How does that work? Watch your Device. Is it smoothly changing between 96 and 44.1?
 
I'm not positive if you will accidentally lock your device by having that RME Driver window open from the system tray or not. You'll have to try it.

The taskbar Fireface USB dialog reports exactly the same asif I open it in Sonar.  There were no other apps open when this problem was occuring.
 
The "share drivers with other programs" was unchecked.  I have now checked it and see what happens.

mettelus
As I am not sure of the sampling rate in a project, I am grateful for this handshaking (which can be undermined if multiple applications are accessing the interface, especially Windows).

This made me wonder whether 200bpm had the 96K project open when he started the video recording. Perhaps the video recording latched onto the RME, locking it to 96. Any other application could do the same... like @'s web browser example where he's using Youtube and that locks the interface to the current sample rate.
 
Then when 200bpm tries to alter the sample rate using Sonar, the other running application blocks the change.
 
As he reports, opening another proj at 96 doesn't exhibit the same behaviour.
 
200bpm, feeling good about this?

200bpm
Craig,
In the first post, I linked exactly the problem I was having.  You're trying to seem smart but failed at basic reading comprehension.

The problem is that you don't provide the correct material to read, not that there is anything wrong with my reading comprehension. To recap:
 
 in the first post you posed a problem. The second post proposed a solution. YOUR NEXT post said thanks, that an unassigned bus had gotten in there.
 
Two other people, myself included, added more information you might find helpful. It seemed the problem was solved.
 
Then you segued into what appeared to be a different topic, that of "outputs dropping." You see, I do have excellent reading comprehension, and the words "silent busses detected" are different words than "dropping outputs." So given that you had already indicated the problem was solved in post 3, I assumed - given the lack of an introduction, like "It wasn't just an unassigned bus, I am now encountering..." - it was a different problem.
 
 
 

 

200bpm
I dont give any extra respect, consideration, or fealty to anyone based on post count or "reputation"; either help or don't help.  People who play act as internet police have serious problems.  This place is no more yours than it is mine because I paid for the software just like you.  Don't try to enforce internet hygeine, syntax, spelling, or comprehension.  Don't try to serve as informal PR for Cakewalk, making it seem like bugs are user error or lack of understanding.   Either help or don't help, the rest of the BS do on your own time.

 
After reading your personal attack on someone who merely provided a compendium of helpful tips from himself and other regulars who have learned how to take maximum advantage of these forums, I'm choosing "don't help." 

Just in case Windows is "locking on" to your interface, also be sure you set your sampling rate in Windows as well. I am not sure of your O/S, but in Windows 7 it is in "Change Sound Card Settings"->select the interface->Properties->Advanced tab on the next pop-up windows. For some reason I have a hunch you may be set to 16 bit there, but not sure.
 
Windows acts as the middle-man between the interface and SONAR, so if your RME is set as default (mine is not, as I use the Realtek chip for Windows garbage), Windows may be playing part in your issue.

@mettelus,
 
Windows doesn't interfere on my PC. Doesn't mean it isn't, but those things you described are no issues for me on Windows 8.1 using that Asio Drivers from RME.

One last thing. It maybe time to clean install X3. Be sure to run as administrator when you do. After installing check to see that the SONARPDR.exe has the right security settings too.
 
When first starting for the very first time let it test your audio interface. You may still have to manually set everything right in preferences.
 
 
 
  

I am out on vacation and just saw your video. Firstly, its very unfortunate that you are taking an aggressive attitude with people who are trying their best to help you. Try and understand that this is a peer to peer forum. If you really need timely support for a problem you have the best avenue is to call tech support since they have chops to step through a problem online with you. Either Cakewalk or RME support could have helped in this case. 
 
On looking at your video it appears that in your RME setup when you switch to 96K from a 44.1K setup certain hardware outputs are not being seen by SONAR which is whats triggering the silent buses warning. When an output goes away for a bus that was previously routed to it, SONAR will replace that output by "NONE" in order to avoid routing to a random out. When it does that it warns you about it thats all. The root problem to investigate is why the device is not showing the outputs in question when you switch from 44.1 to 96K when indeed the output was present previously when you created the project. This is clearly an RME specific issue and will need someone with the same hardware and driver to repro it. I actually have a UFX at home but cannot look into this presently since I am out travelling for the next week. You can either contact Cakewalk or RME to get to the bottom of it. I think RME might be more equipped to help in this since they will be able to advise you why the outputs change. I personally have never noticed this on my UFX but it could be since I may not be actually using the specific outputs that you are using.
 
Please post a screenshot of your audio preferences page showing all the output devices in use when you are in 44.1K mode *and* after loading the 96K project. This should show which outputs specifically are being removed if so. I'm curious if they are actually being removed or if they are just unchecked in the configuration. Its common for some audio interface to scale back the number of outputs based on the sample rate but I dont know the specifics for the UFX offhand. Anyway it will be easier to diagnose given this extra information.

The UFX will scale back the ADAT channels when switching sample rate. I'm not speaking to 200bpm's issue so much as just stating this fact for Noel.

Noel Borthwick [Cakewalk]
I am out on vacation and just saw your video. Firstly, its very unfortunate that you are taking an aggressive attitude with people who are trying their best to help you.  

The problem is Craig Anderton's haughty attitude and passive aggressive behaviour.  If you read this thread, I posed a question and linked the message I was seeing from the Sonar Documentation.
 
Craig then told me to search Google and POSTED THE SAME EXACT LINK I posted in my original query.  He later went on to chide and tell me that I need to provide more information if anyone is going to help, yet another respected user fully understood what I was saying and provided some suggestions.
 
Craig acts this way and he needs to be called out on it.  I have worked in software engineering for 20+ years and geeks are notoriously bad at deciphering social interaction, attempting to apply occams razor to nuanced situations that they do not understand.  
 
You should just stay out of the social commentary.  As I said in another thread help or don't help.  The rest of the posturing, passive aggression, internet policing is a waste of everyone's time.
 
So your official answer is that Sonar can't switch between different sample rates without dropping outputs because there is something wrong with the RME drivers.  Gotcha. (The outputs are still listed in Sonar devices, so Sonar can see them, it just drops them from certain busses.)
 
BTW, I have 200+ posts and still can't post screenshots.  That  alone is enough to make anyone hostile.