** URGENT ** Need Optimization Help

[metamorphosis]

Cool. If you DO need to roll back to Win7 at some point, look into the hack which enables ongoing security updates (ESU program) for regular consumers.

And see my sig for more optimization stuff.

[Pictus]

This is gotten serious enough that I had to start this thread. I recently upgraded from Windows 7 to Windows 10 running Cubase 7.07. I7 with 16 GIG RAM and 2 SSD drives. So while it's not state of the art, it's not a wimpy computer. Previous to the update to Windows 10, it was running reasonably well. I could run 35 instances of Omnisphere 2 with no problems.

Some tweaks for NVIDIA, AMD and Windows 10 that makes difference...
viewtopic.php?f=16&t=503585&p=7624448#p7624448

[jackoo]

Do you have jbridge?
If there is only 1 plugin making the mess, I would bridge it in performance mode with jbridge (with a separate GUI thread - so GUI in extra window).
Adds one extra buffer, while the plugin will be dispatched on a separate core. And because of the extra buffer, there will be negligible impact to the realtime performance.

I'd also try in another DAW just to see if that's really your issue.
And also, if one plugin is causing realtime performance issues, you should immediately see your meter drop when you disable it. And when only that plugin is used, without anything else, you should see the same bad performance on the meter (or at least a serious contribution to the performance meter)

[wagtunes]

Do you have jbridge?
If there is only 1 plugin making the mess, I would bridge it in performance mode with jbridge (with a separate GUI thread - so GUI in extra window).
Adds one extra buffer, while the plugin will be dispatched on a separate core. And because of the extra buffer, there will be negligible impact to the realtime performance.

I'd also try in another DAW just to see if that's really your issue.
And also, if one plugin is causing realtime performance issues, you should immediately see your meter drop when you disable it. And when only that plugin is used, without anything else, you should see the same bad performance on the meter (or at least a serious contribution to the performance meter)

1. Why would I use JBridge on a 64 bit plugin? Makes no sense.

2. I don't have another DAW. At least none that I actually use. So I wouldn't know how to tell if the plugin was causing performance issues or not.

3. When I disable the plugin or freeze the track, yes, the meter drops like a rock. It's definitely the plugin. There is no question about it.

[jackoo]

1. Why would I use JBridge on a 64 bit plugin? Makes no sense.

Because in performance mode, you make the contribution of one plugin to the VST performance meter (realtime perfomance) neglijible. It will only show as CPU usage in task manager.
Basically because it runs on a separate CPU core and there is no overhead with talking with the original audio thread because of the extra buffer. The penalty is extra 1 buffer of latency (only for that plugin - I usually find this acceptable).

Think of it like running in parallel with minimal impact to the series calculation, in your main audio thread.

On my ancient computer, I used to do this to practically double the power of my CPU because I had 2 cores. This is regardless to whether the host has multicore support. The host can use multiple core, but the main audio thread is not something you can multicore efficiently. Without the extra buffer, bridging is less efficient than a native load, of course. But with the extra buffer you're just freeing your main audio thread.

[DarkStar]

I'm curious: did MODO Drums show up similar problems when you were using Windows 7?

In any case, report the problem to IKM Technical Support for investigation / fixing.

[wagtunes]

I'm curious: did MODO Drums show up similar problems when you were using Windows 7?

In any case, report the problem to IKM Technical Support for investigation / fixing.

MODO Drums was always a pig. But after going to Windows 10 it is almost unusable.

[wagtunes]

1. Why would I use JBridge on a 64 bit plugin? Makes no sense.

Because in performance mode, you make the contribution of one plugin to the VST performance meter (realtime perfomance) neglijible. It will only show as CPU usage in task manager.
Basically because it runs on a separate CPU core and there is no overhead with talking with the original audio thread because of the extra buffer. The penalty is extra 1 buffer of latency (only for that plugin - I usually find this acceptable).

Think of it like running in parallel with minimal impact to the series calculation, in your main audio thread.

On my ancient computer, I used to do this to practically double the power of my CPU because I had 2 cores. This is regardless to whether the host has multicore support. The host can use multiple core, but the main audio thread is not something you can multicore efficiently. Without the extra buffer, bridging is less efficient than a native load, of course. But with the extra buffer you're just freeing your main audio thread.

I guess it's worth a shot. Right now I'll try just about anything.

[jackoo]

really keen to see if that helps

[wagtunes]

really keen to see if that helps

Doesn't work. Cubase indexed it on startup but won't show under bridged vsts. I did a search. Can't find it anywhere. Only the original vst shows.

[jackoo]

Sorry to hear...
That's a Cubase issue...

https://helpcenter.steinberg.de/hc/en-u ... separately

[..]
you can specify the scanned locations under "Devices" > "Plug-ins manager"("former plug-ins informations" > "VST 2.x paths
[..]
Specific settings for jBridge

If using jBridge, it is wise to use an additional folder.

"VST Plugins (bridge)" will only contain the original 32-bit version which jBridge will use to create the .64 files in "VST Plugins (jBridge)".
IMPORTANT: In this case, the "VST Plugins (bridged)", folder must be hidden to Cubase 64-bit, which will scan "VST Plugins (jBridge)".

So maybe you can put the bridged dll in another folder such as "VST Plugins (jBridge)".
Otherwise Cubase is stupid for not loading 64bit to 64bit bridges.

I used to do this in hosts which allow me to use any specific dll.

LE: Disclaimer: I didn't try this...
So i interpret these instructions as follows: put the original 64bit dll in a folder which cubase doesn't scan. Put the bridged 64bit dll in a folder which Cubase does scan... (and regenerate the bridged dll so that it corresponds to the new path)
If this is specific to one dll / one plugin, this might be worth it. But it's up to you to decide if trying these workarounds is worth it...

Cheers!

[wagtunes]

Sorry to hear...
That's a Cubase issue...

https://helpcenter.steinberg.de/hc/en-u ... separately

[..]
you can specify the scanned locations under "Devices" > "Plug-ins manager"("former plug-ins informations" > "VST 2.x paths
[..]
Specific settings for jBridge

If using jBridge, it is wise to use an additional folder.

"VST Plugins (bridge)" will only contain the original 32-bit version which jBridge will use to create the .64 files in "VST Plugins (jBridge)".
IMPORTANT: In this case, the "VST Plugins (bridged)", folder must be hidden to Cubase 64-bit, which will scan "VST Plugins (jBridge)".

So maybe you can put the bridged dll in another folder such as "VST Plugins (jBridge)".
Otherwise Cubase is stupid for not loading 64bit to 64bit bridges.

I used to do this in hosts which allow me to use any specific dll.

LE: Disclaimer: I didn't try this...
So i interpret these instructions as follows: put the original 64bit dll in a folder which cubase doesn't scan. Put the bridged 64bit dll in a folder which Cubase does scan... (and regenerate the bridged dll so that it corresponds to the new path)
If this is specific to one dll / one plugin, this might be worth it. But it's up to you to decide if trying these workarounds is worth it...

Cheers!

I did put it in another folder. I have a bridged folder. The plugin is showing there. It's just not loading into Cubase, which is odd because all my other bridged vsts are showing up.

[jackoo]

The point is that the folder with the original 64bit dll should not be in the scan path of cubase... Are you sure it's not scanning both? Because then, it should not be aware of the original...

So I mean put this particular original 64bit dll outside the folder with your normal 64bit plugins...

The other plugins that are bridged are probably 32bit. And Cubase thinks it might not make sense to do 64-bit to 64bit... I'm sorry if this is more trouble than it's worth...

[wagtunes]

The point is that the folder with the original 64bit dll should not be in the scan path of cubase... Are you sure it's not scanning both?

So I mean put this particular original 64bit dll outside the folder with your normal 64bit plugins...

I've done this before with all my 32 bit plugins. It shouldn't matter. I shouldn't have to delete my 64 bit dll from the plugins folder. The bridged vst, which is in the sub folder bridgedvsts, SHOULD show up when Cubase scans. In fact, when it scanned, I could see it indexing MODO Drum.64 in that folder. It is just not showing up when I go to instruments in Cubase and look in the bridged folder. Even doing a search for MODO only the one drum module shows up.

It works fine with all my other vsts NOT deleting the original file. It should work fine here too.

[jackoo]

no, do not delete it!!!!! otherwise it remains deleted, and you can't recover it.
The bridged dll is just a pointer (it's a dummy file! only a few kb in size)... it doesn't have all the info in the original.

Just move the original!
I agree with you that you shouldn't in principle have to do this...