From various posts by Steinberg and VSL employees on various forums and support posts, here's the situation as I best understand it.

There was an issue internal to Cubase which has been fixed. However this won't do anything until VSL update VE Pro, which they cannot yet do. The VST2 version is incompatible with ASIOguard. The VST3 version VSL cannot update until Steinberg updates the SDK, which has no time frame to be done. So until that unknown time, users are unable to use VE Pro with Cubase 8 without severe side effects.   Its probably best to disable ASIOguard from VE Pro in the plugin manager until this whole issue is resolved.  Unfortunatly it looks like this whole issue won't be fixed any time soon.

This sums it up as far as I can tell.  I am so anxious for this to resolve an Vienna to get this implemented.

@noiseboyuk said:

From various posts by Steinberg and VSL employees on various forums and support posts, here's the situation as I best understand it.

There was an issue internal to Cubase which has been fixed. However this won't do anything until VSL update VE Pro, which they cannot yet do. The VST2 version is incompatible with ASIOguard. The VST3 version VSL cannot update until Steinberg updates the SDK, which has no time frame to be done. So until that unknown time, users are unable to use VE Pro with Cubase 8 without severe side effects.   Its probably best to disable ASIOguard from VE Pro in the plugin manager until this whole issue is resolved.  Unfortunatly it looks like this whole issue won't be fixed any time soon.

This post has been interesting reading. I had never used Ensemble before in previous versions, so v5 is my first experience. I have pretty much been unable to use this (running slave on same machine as DAW, not had opportunity to try via networking but suspect the results will be the same or worse). I found similar advice re disabling asio-guard in plugin manager on the steinberg forum, this hasn't stopped VSL from corrupting any project it's inserted into along with causing other mysterious issues (although I'm still to 100% confirm it's VSL doing it, the first project I've made deliberately not using VSL seems to have solved this issue also). Really hope Vienna & Steinberg can sort this out between them, as it's looking like going back to having to open a new project for anything involving kontakt libraries.

As it seems the answer to when it'll be fixed is "when the new SDK is released ie we do not know", where would be a good place to lurk occasionally to receive updates on this issue? It's disappointing that to use the program I bought to solve my RAM-problem, I have to turn off a feature that then gives me a huge CPU problem :)

@dlpmusic said:

VE PRO VST2 does not support ASIO-Guard 2 you have to disable ASIO GUARD, also VSL has to implement a VST-3 interface that supports ASIO- Guard. 

They have been informed about this. 

I thought I'd bump this thread since I'm sure many are eager for this fix -- looks like Steinberg has version 3.6.5 up from a few days ago. I couldn't find anything on this topic in the documentation with a quick look, but hopefully it's buried there somewhere. Any news on the issue?

This sounds like good news that a new SDK is posted.  Can we get a response from Vienna?   Do you now have the information to fix VE PRO 5 to behave correctly with ASIO GUARD 2?

@dlpmusic said:

VE PRO VST2 does not support ASIO-Guard 2 you have to disable ASIO GUARD, also VSL has to implement a VST-3 interface that supports ASIO- Guard. 

They have been informed about this. 

I thought I'd bump this thread since I'm sure many are eager for this fix -- looks like Steinberg has version 3.6.5 up from a few days ago. I couldn't find anything on this topic in the documentation with a quick look, but hopefully it's buried there somewhere. Any news on the issue?

It's looking hopeful.  Fabio Bartolini from Steinberg posted this today:

"The new extended VST SDK (v3.6.5) has been released a few days ago. The new version supports the scenario described above by Mr. Seleteg.

http://www.steinberg.net/en/company/developers.html"

Would be great if you can let us know if this is indeed what you've been waiting for, Vienna.

Can we get a reply from Vienna on the status?  It would be great to get a comfirmation that you have what you need to fix the ASIO GUARD 2 problem so we can stop making requests to Steinberg.

@noiseboyuk said:

It's looking hopeful.  Fabio Bartolini from Steinberg posted this today:

"The new extended VST SDK (v3.6.5) has been released a few days ago. The new version supports the scenario described above by Mr. Seleteg.

http://www.steinberg.net/en/company/developers.html"

Would be great if you can let us know if this is indeed what you've been waiting for, Vienna.

Hi everybody, 

I have informed our development team about this, hope they can get back to you soon. 

Best, 
Paul

Please keep us posted Paul.

Many of us have not chimed in on this issue, but it's a huge deal for anybody usiing Cubase 8 and (in my case) Nuendo 7.   Here's hoping the new SDK allows you to resolve the issue.

Jules

Seems like enough time has passed. It would be great to get some sort of comment back from Vienna when we will see this fix implemented.

Martin or Paul....any word on this yet?

Hi, 

I talked to Martin, here is his answer: Prefetchable support disabling will be available in the upcoming new version of VE Pro. 

So Asio Guard will be disabled programmatically in the VST3 plug-in, every other change would introduce a dramatic raise in latency. 

Best, 
Paul

Thanks for the post Paul.

However, I'm not entirely clear on what this means and would be very grateful if you or Martin could clarify.  This is my current understanding:

Selective disabling of ASIO Guard on a per-plugin basis (e.g. just for VE Pro) is already available in Cubase 8 and Nuendo 7.  I have tested this (and tried to work with it) in Nuendo 7, and sure enough it does stop the issue whereby audio drops out every time a different track is selected.  HOWEVER, it means that CPU usage jumps dramatically, to the point where templates which run comfortable under previous versions of Cubase and Nuendo no longer run at all in Cubase 8 and Nuendo 7. 

In short, the efficiencies which ASIO Guard brings to Cubase 8 and Nuendo 7 are basically essential in order to keep large templates running at all.   If ASIO Guard is disabled for VE Pro, the loss of CPU efficiency renders many large templates unusable, and massively handicaps the usefulness of VE Pro.

My understanding of the situtation was that VSL needed to implement a VST-3 interface which supports ASIO Guard.  Your statement below appears to suggest that a new version of VE Pro will simply disable ASIO Guard support within the plugin, which leaves us in the same situation we're currently in.

Hopefully I have misunderstood.

Jules

It would be great if you can clarify what this means.

Hopefully.....does this mean we can change tracks in Cubase without the 2 second hang/pause in the audio?

@Paul said:

Hi, 

I talked to Martin, here is his answer: Prefetchable support disabling will be available in the upcoming new version of VE Pro. 

 

So Asio Guard will be disabled programmatically in the VST3 plug-in, every other change would introduce a dramatic raise in latency. 

Best, 
Paul

@dlpmusic said:

It would be great if you can clarify what this means.

 

Hopefully.....does this mean we can change tracks in Cubase without the 2 second hang/pause in the audio?

You can already do this in Cubase - you just need to disable ASIO Guard for VE Pro.

The problem is, the loss of ASIO Guard means VE Pro uses signficantly more CPU resources than it would otherwise, leading to CPU overloads etc.   Which is why we've been waiting for VSL to implement a VST3 interface which correctly supports ASIO Guard 2, so that we can re-enable ASIO Guard for VE Pro, not suffer the CPU issues of having it disabled, and also not suffer the audio dropout problems.

Whether this is what VSL are looking to achive remains somewhat unclear (in fact rather unlikely) from my interpretation of Paul's post.

You misunderstood me.  Currently you can use ASIO GUARD 2 with VE PRO 5 but with the annoying audio muting.  If the prefech means we can still use it as is but the audio muting goes away I would assume it would still give us the CPU gain benefits that you can clearly see right now if you put up with the 2 second audio pause.  For me there is also additional problems that occur with VE PRO 5 in regards to having ASIO GUARD 2 on.  I have a very large template that takes Cubase about 10 seconds or so to start an export.  If I enable ASIO GUARD 2 with VE PRO 5 my exports take more then 1 1/2 minutes to begin exporting and a 1 1/2 minute delay for Cubase to become responsive after the export.

Disabling the plugin VE PRO 5 from using ASIO GUARD 2 within Cubase is a waste of time for me as there are almost no benefits acroos my system.  Turning it all on produces incredibly low CPU on the VE PRO machines.....that is what we all want.

So......if we still can get the benefit of the low CPU and no audio muting that might be good enough.

@dlpmusic said:

So......if we still can get the benefit of the low CPU and no audio muting that might be good enough.

I didn't really get that out of it, seems like there's no other way except to disable ASIO Guard for VE Pro.

 I really dislike that idea, because with Cubase 8 the performance with all VSTis including VE Pro hosted ones has gone down, and only with ASIO Guard enabled does the whole thing make any sense. So there needs to still be a way to manually enable it for heavy sessions, even if VE Pro will default to disabled.

I am being optimistic hopefully....not sure what they mean.  We need it explained.

Currently there is no other way to mitigate the audio muting, than to disable ASIO Guard (2) for the VEPro plugin. With the help of the new interface introduced in the VST3 SDK, I have set VEPro to automatically disallow going into ASIO Guard mode in the upcoming version.

As I have described earlier, the cause for the mutes is the Cubendo audio engine reconfiguring itself as soon as the buffer size (and with it, the latency) of the plugin changes. Other hosts (such as Logic) get around this problem by queuing an engine/PDC reconfiguration until the next stop/start cycle.

The only possibility I see to handle AG2 from our side right now, would be to make the plugin operate completely asynchronously, but this would also mean we would have to adapt the overall latency to be higher than currently, which we are reluctant to do.

I am also wondering if it really is the case that plugins running without AG2 are performing worse in C8 than they were without AG in C7? Did any of you guys do any tests on this?

Thanks,

Yes....I have done significant testing.  For instance I have a machine that runs nothing but EW PLAY running Hollywood Strings and Brass.  Play is very demanding and without playing a single note my very powerful I7 QUAD core sits at 78%....before I play a single note.  My Cubase buffer runs at 128 samples.  With ASIO GUARD 2 on its high setting that 78% drops to just 16%.  At medium setting it drops to about 23%.  These results are similar across all 5 of my slave machines.  This an absolute ground breaking difference.  

There must be some sort of solutiion to resolve this.  Is it possible to have a preference to run in asynchronous mode?

We desparately need this feature to work.

-Danny

@MS said:

Currently there is no other way to mitigate the audio muting, than to disable ASIO Guard (2) for the VEPro plugin. With the help of the new interface introduced in the VST3 SDK, I have set VEPro to automatically disallow going into ASIO Guard mode in the upcoming version.

 

As I have described earlier, the cause for the mutes is the Cubendo audio engine reconfiguring itself as soon as the buffer size (and with it, the latency) of the plugin changes. Other hosts (such as Logic) get around this problem by queuing an engine/PDC reconfiguration until the next stop/start cycle.

 

The only possibility I see to handle AG2 from our side right now, would be to make the plugin operate completely asynchronously, but this would also mean we would have to adapt the overall latency to be higher than currently, which we are reluctant to do.

 

I am also wondering if it really is the case that plugins running without AG2 are performing worse in C8 than they were without AG in C7? Did any of you guys do any tests on this?

 

Thanks,