My Ensemble startup time is about 5 minutes, all of it because it is "scanning plugins". The bizarre thing? I have 5 plugins - Synchron Player, Synchron Pianos, Vienna Instruments Pro, Kontakt 6..1.1, and Omnisphere. Closing Ensemble is not as bad, but it does still take about 2 minutes.

I am running a core i7 8700k with 64 GB of ram, Kontakt runs on a 10 TB spinning drive, everything else is installed to an M2 SSD (the libraries are all stored on a spinning drive, but the actual software and plugins are on the SSD).

This has nothing to do with the number of plugins, since I only have two plugins that are not Vienna products, and omnisphere + Kontakt are not anything unstandard. I would be surprised if anyone writing music does not have these two products installed, Ensemble should not have any issues with these two plugins.

VEP 7 is also pretty unstable, frequently crashing whenever I have a MIDI track loaded in Cubase with an instrument already loaded in Ensemble and I delete the track from within Cubase 10.4. If it didnt take 5 minutes to re-open it and another 10 minutes to load my orchestral libraries in, it wouldnt be so bad, but it sure does put a damper on creativity to have it crash and know that its going to be 15 minutes before I can start working again.

VEP 6 had no such issues, and by the time I upgraded to VEP 7, VEP 6 was so wonderfully fast and stable. I expected issues initially, but not a year after its release.

Yes.....very depressing that these issues persist.  I like you are forced to stay with VE PRO 6 and am doubtful I will ever be able to use VE PRO 7.  Not that I don't have some severe iassues with VE PRO 6....I do and upgraded to VE PRO 7 as I assumed that would be the only way to get these problems resolved....... waiting like the rest of you.

The fact is that there does not seem like a huge amount of people complaining, so I am doubtful they will take this serious enough to solve the issues.  I don't understand how this can be so hard to solve when these pfoblems were not an issun in VE PRO 6.

Out of interest, is anyone having these issues _not_ using Cubase/Nuendo?

I'm having the same issue.  Template with zero plugins loaded, cubase 10 closes and opens very slow.  If I disable all the outputs of Vienna in vst instruments, it's a little bit better.   Activated and disablilng those outputs takes FOREVER.  I'm still using VE 5 because of the awful folder organization, which is by vendor and developer instead of the neat folders I created.  I got tired of searching in a separate window for program files - vst plugins - Eqs, compressors, etc.

Maybe folder organization will come in version 10 lol.

BTW I loaded an orchestral template with over 200 vienna 7 outputs engaged in cubase, could not use it at all.

From another user:

"The issue is they added a ton of automation lanes to VE Pro that means cubase auto creates all these auto lanes per return lane from an instance. So say you have 130 return stereo lanes, each one in the Cubase mixer now creates 20 auto lanes too. So now you have the Cubase mixer trying to create 2,860 mixer lanes every time it tries to open a session instead of 130. And there's no way around this with the VST3 standard -- if the plugin presents auto lanes they will be created in the DAW mixer."

Just an update - I built the same exact template with VE 6 and it loads more than 70% faster.  Even in standlaone.  Loading plugins, even moving buses or channels around takes forever.  Engaging 32 outputs in cubase took over a minute, with VE6 took 10 seconds.  It's pretty bad.

@casalena said:

Just an update - I built the same exact template with VE 6 and it loads more than 70% faster.  Even in standlaone.  Loading plugins, even moving buses or channels around takes forever.  Engaging 32 outputs in cubase took over a minute, with VE6 took 10 seconds.  It's pretty bad.

That would be in line with the earler automation lanes post. I will be going back to VEPro 6 for my next project.

The only thing I miss is the manual color pallette for track colors :)

Fixed in latest update for me, runs just like V6 now.

@casalena said:

Fixed in latest update for me, runs just like V6 now.

Yes!  I can use VE PRO 7 now! I still have some long standing open issues with Cubase/VE PRO....but Steinberg is aware and said they are currently working with Vienna to solve hopefully soon.

Yup, confirmed working for me as well now

Thanks guys!!!!!

This problem has come back in 7.1.1239! Aargh!

Is anyone else also experiencing super-long load times an hangs when doing an export from the DAW?

Thanks.

Hi, 

We're on 7.1.1245 since today. 

Please refresh or restart your Vienna Assistant to get the latest update!

Best, 
Paul

@Paul said:

Hi, 

We're on 7.1.1245 since today. 

Please refresh or restart your Vienna Assistant to get the latest update!

Best, 
Paul

I tried updating via VA on Mac but it seems to have removed the VEPro VST3 plugin completely in the silent install. Windows server side went ok. I'll try uninstalling and re-installing. 

@Paul said:

Hi, 

We're on 7.1.1245 since today. 

Please refresh or restart your Vienna Assistant to get the latest update!

Best, 
Paul

Hi Paul - nope. Sadly an uninstall of the VEPro via VA and then a fresh install via VA only installed the surround version of the VEPro VST3 on Mac.

@Paul said:

Hi, 

We're on 7.1.1245 since today. 

Please refresh or restart your Vienna Assistant to get the latest update!

Best, 
Paul

Hi Paul - 

I've updated to 7.1.1245 but this hasn't made a difference. It's behaving like it did before that fix was made a couple of years ago - so it's taking horrendously long to load projects. There's also a, presumably related, problem with offline bounce. It takes ages to switch from normal playback mode to MIXDOWN mode. I just timed an offline bounce and it took 4mins50seconds to begin the bounce while Cubendo waits for VEPro. It then also takes the same time again at the end of the export while waiting for VEPro to switch back out of MIXDOWN mode to normal playback.

This is a real time-killer right now. 

Thanks for your help.

Graham