UAD-1 w/jbridge (and Cubase performance meter woes)

Cubase
#1

The performance meter in Cubase seems often not accurate - comparing it to windows performance meter in task manager. I’d like to be able to reliably check performance with that Cubase meter, but I just don’t trust it. I tested this quite extensively yesterday.

Anyway… a UAD-1 card (running 32-bit plugins) using jbridge works in C9, yes, except that the jbridge auxhost.exe process eats CPU such that any gain made by offloading processing to the UAD-1 card, is erased by the necessary jbridge auxhost process that runs concurrently …which sucks.

So, with a UAD-2 device, then, I presume running the native 64-bit UAD plugins (NOT through jbridge) doesn’t have this problem?

And with Cubase 9 dropping support for 32-bit plugs, I wonder if it’s still possible to find from the Cubase 8.5 folder the VST Bridge files, drop them into Cubase 9, and maybe get it to work? …and if that makes the CPU performance any better?

(musings of an early adopter…)

#2

for UAD1 Plugins in JBridge activate “run in existing auxhost” in Settings

#3

I do that, because it is (or was) necessary to run more than 1 UAD-1 plugin using JBridge. I’m now going to try enabling “performance mode” in the auxhost.

#4

Yes and also try enabling and disabling asio guard (must be done for each plugin in plugin manager). I will check here too tomorrow.

#5

Vinark, turning off ASIO guard altogether in Device Setup fixed that issue. Wow. Now to turn it back on and turn off ASIO guard on all UAD-1 plugins, and test. I’ll report back… Trying to wrap my head around ASIO guard…

#6

Follow up: And now disabling the ASIO Guard on the individual plugins at first seemed to have worked… then didn’t… then when I turned off and on each plugin (the on/off buttons for the actual plugin processing, not the active/inactive ASIO guard buttons in the plugin manager), it fixed itself… and seems to remain that way (though I didn’t run a very long session, or open up another UAD plugin.) So much to test when stuff like this happens. Nice to know that we’re on the hunt. Thanks for the tip. I’ll update when I know more…

#7

Follow up #2: My system has crashed 3-4 times today, total lock up, working inside of a UAD-1 plugin that’s been jBridged …even when the ASIO guard / Performance meter seems to be working correctly by setting the ASIO guard to “inactive” for all the UAD plugins (inside Plugin Manager). And even when the computer doesn’t lock up, just turning on/off UAD plugins, inserting new ones, etc., would frequently make the performance meter spike again, stay spiked, and also show in the Windows task manager as my CPU working harder. The fix for this always came down to turning off a UAD plugin, but usually a specific one that wasn’t always the same one.

Basically, UAD-1 plugins via jBridge is one sketchy experience …on my system …rendering my 1176, LA2A, Pultec Eq, EMT140 rather useless. The crashes only occurred while tweaking the knobs, by the way, so if I just set it and forget it, I might be in luck. (ugh) I think I will send a note to the jBridge fellow, see if we can’t figure this out.

Note that since all these UAD plugins are set to work inside the same auxhost.exe process, I think that’s where the problem might lie. If they each could have there own process, I think the problem would be resolved. I’m no programmer… But, as I said above in this thread, using one auxhost.exe process is how UAD-1 plugins needs to be set in terms of jBridge, otherwise you only get to insert a grand total of 1 UAD plugin on your project.

Fun stuff, this 32-bit farewell party, ain’t it…

#8

Thanks for the info. I have 3 UAD-1s. They work OK with jBridge 1.75–after working with Jaoa. These are the only 32 bit plugs I still use.

However, I am strongly considering getting a UAD-2 Solo or Duo to run these in 64 bit, simply because I routinely access CPRs which are as much as 10 years old.

When I originally bought UAD-1, the plugs were a LOT less expensive than they are now. As the years have gone by, I have found Native alternatives that are fine for my needs—and the need for external horsepower has gone down. I will likely never buy any of the newer UAD-2 plugs which are, IMO, CRAAAAAAAAZY expensive.

So I’m basically concerned about backward compatibility. Going forward I am weaning myself off UAD completely… as I did with PoCo 4-5 few years ago.

#9

I feel the same way. $2000 for a crazy fast computer rather than an Apollo makes good sense. Reminds me of the days when i was considering buying into the Creamware line of products… but stuck with the native Cubase.

I believe I have 1.74 of jBridge and I guess the 1.75 is a beta. Did you have a problem with 1.74 similar to mine above? high CPU usage in the auxhost.exe, and misreporting in the Cubase Performance meter?

I can follow up even more about my experience now: In an empty project, I don’t have the odd UAD problem. I cannot duplicate it… The problem only comes up in my basic .cpr template I call up which has a bunch of plugins preloaded (but not turned on). Something to do with the complexity of that template project vs. an empty project seems to tank things, and keep them tanked even if I remove all extraneous tracks and plugins.

It’s a total of 6 UAD 1 plugins that I’m running this test with, putting my UAD meter at 90% use. When the problem happens, if I toggle one or two of the UAD plugins off and back on, some times I get the problem to go away, but only briefly. If I turn them back off and on again, the problem can come back. Odd.

Wow, I’d love to get this one banged out so I don’t have a heap of metal taking up 1 glorious legacy PCI slot in my old ass machine. :slight_smile:

#10

I see that 1.75 beta version of jBridge is posted at Joao’s site with a description that it should resolve issues that crop up with Cubase 9. I’ll give it a go…

https://jstuff.wordpress.com/2016/12/08/jbridge-1-75-beta/

#11

follow up: it resolves 1/2 of the issues I have. It fixes the spiking in the Cubase meter, but the weird CPU usage issue still exists in Task manager. (turn a bunch of UAD-1 plugins on, in my case 6, and the auxhost shows 20-23% usage on my Quad core Intel core 2 CPU. turn a couple off and back on again, the CPU releases and goes down to like 2%. Go to import an audio file and click the audition button and the CPU goes back up to 22% again.) I’ve been emailing Joao about this… More to come, I guess…

#12

This just in: I’m now getting the dreaded ‘One Or More Plug-Ins Have Been Disabled’ error in a particular CPR. The MADDENING thing? It ain’t happening in -other- projects. At the moment, I have -no- idea why one CPR ‘works’ but another does not.

Back to Joao, I guess.

And FWIW… UAD plugs are pretty much the only commercial VSTs I’ve had a problem jBridging.

—JC

#13

Make sure ALL uad1 plugins are set to inactive asioguard! I had same issue (one or more etc) when I missed disabling one plugin.
Also running UAD1 at high loads (above 80%) and at low buffers can cause the extra cpu effect. This has always been the case. It is dependent on: Buffer settings, System PCI slots, Cubase priority settings, Audio card drivers and in our case now, the jbridge priority setting.
If you don’t have the cpu load issue with lets say 10 lighter uad plugs and 50% uad load, I am sure it is the issue I mention.

#14

I already had set the UAD-1 plugins to inactive in terms of ASIO guard but it didn’t make any difference. In fact, I turned off ASIO guard altogether which made no difference… although… now that I have version 1.75 of jBridge installed, I should give it another go.

Regarding the high-load issue of my UAD plugin test setup - If I watch task manager, I see it progressively show the gobbling up more and more CPU as each new UAD plugin is instantiated, until it hits 20-23%… and then I have to do the plugin toggling off/on thing to get it to go back down.

Also, in a virgin empty project, if I put these 6 UAD plugins on and do the exact same test, the problem doesn’t arise… (it arises in a template project I created), so I don’t believe jBridge should take up 20% of my CPU under normal circumstances… because that is 20% of my CPU in addition to 90% of my UAD card’s processors… which is highly inefficient. For instance, in that empty project setup where the problem doesn’t happen, I see the auxhost.exe process run at about 3 or 4% CPU - that’s with all 6 of my test UAD plugins turned on and eating 90% of my UAD card’s ability.

My buffer setting is 1024, with smooth-working drivers for my FW1884 audio device.

Anyway, thanks for your help, I will do some more testing later… including trying the sluggish GUI hack and Opcode 19 checkboxes in jBridge, per a new suggestion from Joao.

#15

If you only bridge UAD1, I did find Jbridge 1.63 the best. I could mail it to you of you want it (PM me your address) and see if it makes a difference.

#16

thanks. That’s good to know. I’m jBridging a few others…

Still banging this one out. Tried “sluggish GUI hack” and “Opcode 19” error tick boxes, but no joy. Double-checked ASIO, etc. with the new 1.75 version of jBridge as well. Luck ain’t mine…

It doesn’t appear to just be a problem with a temporary high usage of CPU… that can be fixed by toggling off/on a couple UAD-1 plugs. Cubase also crashes from time to time as I’m testing this - as I’m removing plugins and adding plugins quickly… which, sure, stresses Cubase quite a bit… but my guess is that stock plugins would handle this sort of thing fine.

Anyway, not sure I want to have UAD plugins on my future projects unless this appears to get fixed, and I’m hopeful since Joao seems to be working on it… I just wish UA had made ONE version of these plugins for UAD-1 that were 64-bit natively. WTH?

#17

I think all your trials are red herrings.

QUESTION: Are the CPRs you’re having problems with, originally generated in C9 or an earlier version?

My theory is that there is something in the CPR itself that is causing the problem. I have no problems with CPRs created in C9. But CPRs originally created in earlier versions -have- caused me problems -sometimes-. And sometimes not.

But -every- problem CPR has been ‘fixed’ by:

  1. Removing EVERY UAD-1 plug and saving the CPR
  2. Re-adding UAD-1 plugs back to the CPR

It’s a pain, but this has worked every time so far. No futzing with jBridge settings or ASIOGuard or -whatever-.

#18

Hmm… That sounds promising. I’ll give it a go when I get some time. Thanks much.