Thanks for checking this out Danny.
 
Here's a recipe that seems to show the problem most of the time on my system using what I think are stock plugs with any UAD system:
 
Start a blank project
Add one audio track, add one bus as an aux send from the audio track, and put some audio in the track.
Add Realverb to the aux send, hit play to hear the beautiful room-like ambience it provides.
Put a legacy 1176 plugin in the track fx bin, hit play.
Copy the 1176 to the second slot in the fx bin, hit play.
If necessary, copy the 1176 again, hit play.
 
What I am seeing is that the Realverb stops processing the sound (but still passes audio, and it's phasey so I think it is not latency-compensated) after one to three 1176 instances.  It doesn't happen with every instance, but it eventually happens every time I test it.
 
The same thing happens with current UAD effects.  Copying the 1176 is just a convenience, the same error happens with new instances.
 
This doesn't happen in Cubase (which has some big differences in the audio engine from Sonar) or Samplitude (whose audio engine is relatively more similar to Sonar's, I think).
 
If you don't see any problems from this, I may have to come back with my hat in my hands, and then eat it...  I can't think of what could be amiss with my system though..

Looking at the UAD System Info panel while testing the same scenario in Cubase, the plugins are not being shuffled between the cards each time I add an 1176.  So, my theory is that whatever Sonar is doing which is causing the plugins to be "reshuffled" is also causing the UAD system to believe that the reverb on the aux send is to be unloaded.
 
Later today I'll see if there are any settings in Sonar that affect this, but for the moment it still looks like there's something broken in the relationship between Sonar and UAD...

brian brock
Thanks for checking this out Danny.
 
Here's a recipe that seems to show the problem most of the time on my system using what I think are stock plugs with any UAD system:
 
Start a blank project
Add one audio track, add one bus as an aux send from the audio track, and put some audio in the track.
Add Realverb to the aux send, hit play to hear the beautiful room-like ambience it provides.
Put a legacy 1176 plugin in the track fx bin, hit play.
Copy the 1176 to the second slot in the fx bin, hit play.
If necessary, copy the 1176 again, hit play.
 
What I am seeing is that the Realverb stops processing the sound (but still passes audio, and it's phasey so I think it is not latency-compensated) after one to three 1176 instances.  It doesn't happen with every instance, but it eventually happens every time I test it.
 
The same thing happens with current UAD effects.  Copying the 1176 is just a convenience, the same error happens with new instances.
 
This doesn't happen in Cubase (which has some big differences in the audio engine from Sonar) or Samplitude (whose audio engine is relatively similar, I think).
 
If you don't see any problems from this, I may have to come back with my hat in my hands, and then eat it...  I can't think of what could be amiss with my system though..

Hi Brian,
FWIW, I just followed your recipe and duplicated your behavior after inserting the very first instance of the legacy 1176. The RealVerb plug stopped processing audio and I got phasing. The phasing looks like it's due to signal being present on the aux bus (where the RealVerb plugin is) and PDC still functioning but since the plug isn't doing anything, in terms of both applying reverb AND inducing delay, the signal on the bus is delayed. This results in two slightly out of sync copies of the audio (one on the track and one on the bus) and thus phasing.
 
Just for kicks I removed the 1176 Legacy from the track, disabled and re-enabled the RealVerb plug to make it work again and then added an instance of the new 1176 Rev A to the track. The symptoms came back immediately, so it's not just the Legacy 1176 that's causing a problem.
 
Something is definitely not working here....
 
Dean

more information -
 
when trying the same thing with the Moog filter instead of the reverb, the Moog also gets disabled, but when re-enabling it I get a message from UAD saying that "the Extra Buffering setting must be enabled when using this host".  This is of course, when Extra Buffering is disabled.  So it strikes me that this could all have something to do with Extra Buffering.

Interestingly, the UAD system info still shows the plugins being "reshuffled" when the 1176 is added, and shows one too few plugins in total (the aux send effect being the missing one).  Then when I hit play, the reverb turns back up in System Info again.

Hi Brian,
 
Well, interestingly enough, I cannot make your scenario happen on my end. Nothing stops sending signal...the reverb and the 1176 continues to send both through my tracks and the bus. I decided to add another audio track with a pro verb and an 1176 after it....both audio tracks worked....the one you made me create, the one I created and the bus with the 1176 and the Realverb was still in tact and sending signal with tails after playback stopped. So I'm stumped as far as that goes brother.
 
I am seeing the FX chain issue in pro channel that Mel mentioned to the T. Thankfully I don't use FX chains in PC but I do use them in my FX bins and they work perfectly for me.
 
-Danny

also, it doesn't disable the aux send all the time - have you tried adding the 1176 several times?

I always have "stream" checked, hence why I can hear effects tails after playback. I never turn that off.
 
Yes, I used multiple instances of the 1176 for the tests for you though it is not my weapon of choice for my stuff. I currently have a project open right now with 7 vocal tracks that have a 33609 and a NEVE 1081 on each track. I have a drum bus with a Fairchild and an instance of dream verb following it, I have a guitar room bus with an 1176SE with RealVerb, a few instances of Helios on a few tracks, an LA2A on my snare and a Fatso on my 2-bus. No issues at all with that line-up. That may not do anything to help you in your situation, but I'm using quite a few UAD plugs in X3 and there are no issues at all. I brought up the plugs while playing the tracks to make sure they were actually doing something and they are working fine for me.
 
I'm not using Sonar x64. Not sure if that has anything to do with anything....I do have 64 and use it on occasion but have had too many issues and anomalies while using it, so I stick with 32 bit without any problems EVER. I have since switched over to all 64 bit plugs when using Sonar 64, but haven't spent much time with it to see if that was my problem. Anyway, sorry I couldn't be more helpful.
 
For what it's worth, all my recording pc's are i7's with 16 gig of RAM, 3 hard drives....one for OS, one for streaming audio, one for samples. We have at least one UAD-2 quad in each box with one that has 2 quads. I run my studio using these pc's roughly 15 hours per day give or take...never any problems (thank God) other than pilot error. :)
 
-Danny

64-bit Sonar here Brian. I'm also on a robust system: intel 4930K, 32GB RAM, 2 UAD2-Duo cards, RME HDSPe MADI fx card. I don't have 32-bit installed and I'm a bit afraid to try....
 
 
Dean

well it's good to know that it's not problematic if I have to go that route....
 
So far, 2 64 bit installs have the problem and 1 32 bit install doesn't - would be great to hear from other people as well.

Will try to get to the x64 test tonight. Yeah, ASIO RME FF 800 at 1024 buffers, 24/48. Will try the x64 as well as on another system using Echo Audiofire 12 just to see if there are any other difference. If I can't get to it tonight, I'll try to get to it tomorrow.
 
-Danny

Danny is right. Its possible that this issue is also a side effect of the plugin chaining API. All versions of SONAR since 8.5 use this custom UA API that we implemented for them years ago. 
 
I was in touch with UA fairly recently about this and their response was that this API is no longer actively supported by them at the host level and only used by them internally now. I was also told that they would add a remedy from their end. From our side I have now removed custom UA chaining support from SONAR for the next X3 update so hopefully this shouldn't be an issue going forward.
BTW this isn't really specific to X3 technically - the only reason that you see a difference in behavior is because the UAD driver seems to be testing for a specific SONAR version and masking the error messages - which is why the some UAD warning messages started popping up in X3.

Finally, a baker with some news on this.  Thanks NOEL!!!!
 
JK
 

Noel Borthwick [Cakewalk]
I have now removed custom UA chaining support from SONAR for the next X3 update so hopefully this shouldn't be an issue going forward.
BTW this isn't really specific to X3 technically - the only reason that you see a difference in behavior is because the UAD driver seems to be testing for a specific SONAR version and masking the error messages - which is why the some UAD warning messages started popping up in X3.

great to hear that you're making progress on UAD issues.
 
To be clear, there is no error message for the issue I am raising.  The only error message I see regularly from UAD effects is the -21 UAD plugins separated by other plugin error.  This is a different problem which actually disables processing on aux sends - I think it could easily also be an issue with chaining behavior, given some of my observations, but there's no error message that used to get masked here.
 
I hope that the problem I am raising is also fixed by your changes for the next update.  Is that likely?
 
Also, any rough idea on a timeline for the fix? 
Thanks.

Interesting. I'm still on UA software 6.4, and it works fine. I can put effects in bins, buses, whatever. Maybe this is an instance where "if it ain't broke, don't fix it" has served me well.