Thank you Paul - I thought that might be the reason.  

Can the unload/exit time for VEPro be sped up, or is this just a side-effect of using a lot of RAM?  My local VEPro template has around 50G loaded, and takes roughly 3 minutes to close without saving (template already saved). 

All samples are on SSDs, as is the OS (Windows 8.1). 

I have two instances of Waves Hybrid Reverb as external fx for Cubase (VEP inputs in Cubase 9.5) setup in my VEP server on my host PC (along with 9 Instances hosting various libraries). 

I can save a new preset with no problems, but overwriting an existing preset (even one I created) causes VEP to crash with an unhandled exception error (Windows 8.1). I have had this happen a couple of times.  VEP completely crashes/exits to the desktop. 

I think there may be a crash dump associated, but don't know where VEP stores dump files. 

Has anyone else seen this with Waves or any other plugins or VIs hosted in VEP?  

With the VI Player, you should save a VI preset when you make tweaks (I do because it doesn't seem that changes aren't saved with the VEPro instance).  Also save the VEPro instance where you are hosting Synchron Strings/VI Player just to be sure the correct preset is loaded when VEPro loads. 

If you are running VEPro outside of Cubase, I think, even when coupled, Cubase will only save the reference to the VEPro instances it is connected to. 

I use VEPro decoupled and preserved, so I don't know for sure, but when coupled, I don't think Cubase saves any information about the VIs hosted in that instance.  I am positive Cubase doesn't save specific VI parameters, so even if you tweak Kontakt 5 in VEPro (outside of Cubase), those changes would have to be saved with the Kontakt instrument or multi.  

Hopefully I understood the problem correctly and that helps. 

Agreed.  I had not used VSL libraries much until now (just VEPro), but this is one of the reasons I bought Synchron Strings, and am adapting my writing to use it more (HW Strings are my usual go-to, but I like Synchron quite a bit). 

There are several library developers that seem to have adopted the "more is better" approach to sampling, and are releasing libraries with ridiculously unrealistic numbers of players aimed at the overhyped "epic" scoring mindset.  But to me, this kind of "scoring" is little more than sound design with musical samples.  True music, and true musical film scores can stand the test of time and be enjoyable a century or more from now.  Most of these sound-design styled scores and pieces will be forgotten 2 minutes before the piece has ended. 

It is good to see that VSL is planning and developing with the essence, purity and beauty of true music in mind. 

I thought it was plugin related, but I only have multiple instances of Play 5 in my slave system.  Removing other plugins seemed to extend the amount of time VEP would remain up, but I'm not sure it really made any difference. 

For sake of comparison, I replaced VEPro6 on the standalone slave system with Cantible for hosting VIs, and it has been running for about 2 weeks now (this works as a replacement as I am using hardware for audio back to the host, and MidiOverLan for midi - I wasn't using VEPro's streaming audio/midi system).  

The problem with VEP's audio engine stopping every couple of days seems isolated to VEPro. 

Yes you can run VEPro as a standalone server outside of DP, on the same computer.  You just need to open a VEPro server instance from your desktop (VEP folder, etc).  Then create the instances you need within that server hosting the VIs you want, and name those instances.  You will connect to those from within DP (this assumes VEPro 6 where instances are contained in a single tabbed window). 

In DP, create an instrument track using the Vienna Ensemble Pro MAS plugin - that is used to connect to each instance in the server.  It will create the first output as part of that instrument (additional outputs would be connected as ins to busses/Auxes in DP).  Midi tracks would need to be mapped to the ports/channels you are using in each instance.

You don't need to worry about the network connection or setup for the local instance of VEP server running outside of DP.   That only applies to instances running on other PCs/Macs where you need to stream audio/midi across the network. 

Is it your DP project that is corrupted, or the VEP server save?

One way to minimize the risk of corruptions is to run VEPro preserved and decoupled, and use a standard template in DP to start every project.  When VEP instances are coupled, they are saved with the project file, which not only takes longer, but creates a much larger project file as well. 

If you setup VEP decoupled/preserved on all slaves, it effectively runs "standalone" and your DP projects simply connect to it.  That way DP projects are saved with only the connection references, and your VEPro server instances can be saved independently, with reliable backups.

VEP6 on my Win7 slaves system was running for 3-4 days before the engine would randomly stop, but after the most recent 6.0.16778 update, it runs less than a day before stopping.  And with the last two updates, we still have the problem that VEP6 always shows 0% cpu usage, so I have to manually test to see if the engine actually stopped on this slave.

Add to this that VEP6 on the host system will randomly stop responding (with both Cubase 9.5 and Nuendo 8), and I lose a lot of time reloading this large template every week.  Even with all SSDs on multiple systems, it takes quite a bit of time. 

I know you can't reproduce this, but some bugs need to be addressed without a repro. I am happy to provide whatever info I can, but VSL may have to dig through the code without a repro.  

Here is the error, and it only happens with DP9.1, and it is 100% reproducible with any Vienna Suite plugin.  It does not happen with only VEPro (MAS) instances in a project, but the error will appear as soon as I load one instance of any Vienna Suite plugin.  So far it does not happen with DP 9.5 (which I can't use for now due to another bug in 9.5). 

I've been working in Cubase for weeks with Vienna Suite, VEPro, etc without a problem. 

Application " has caused the following error:

An important service has become unresponsive.
Please restart your computer to fix this problem.

Please visit <www.eLicenser.net> to download and install the
latest version of the eLicenser Control software in case the
problem persists

 

I already have the latest eLicenser control panel, and as noted, this only happens in DP.  Restarting means relaoding VEPro so not an option for now (just restarted recently anyway - that isn't the problem).  Checked the key, eLicenser reports all licenses without issue. 

When opening a project in DP9.13 with Vienna Suite Hybrid Reverb, I frequently get several elicenser errors, and, if I can get past the error popups, instances of Hybrid Reverb are blank saying no license is found.

In this case, this is a large template with several instances of VEPro6, 300+ midi tracks, busses/auxes and 4 instances of Hybrid Reverb.  I have opened this project successfully a few times, so it doesn't happen everytime, but frequently enough to be a showstopper.

I have seen this happen once with Cubase 9.5 as well, but the other 99.5% of the time it has been fine.  It seems there is some lag in checking for a license, causing a failure when the app opens.  Honestly, this is why I despise copy protection (the time and hence, money, it costs me is quite significant). 

Any ideas?  I needed DP for a cue, and can't use it with Vienna plugins apparently.  No problems with the elicenser key, and I have run maintenance very recently.  

So what if a topic isn't worded the way you think it should be?  Is it the job of posters here to monitor, police and object to thread titles, topics and opinions you don't like, or to judge the intent of other VSL users?  No, it isn't. 

Your opinions are fine, but post them in a thread that is related to your issue.  This thread wasn't about problems with legato transitons. 

How would you like to have a legato transitions thread filled with rebuttals and counter arguments about how great VSL is, or a tangent talking about VSL percussion?   This should be simple - just stick to the topic.

Problems should be addressed separately where the relevant technical issues can be separated from personal opinions.   Come on folks, show some professionalism here and stop pointing fingers at the OP for simply wanting to talk about the positives of Synchron Strings.  Is the world really this cynical?  What's wrong with just reading, and moving on?  I can't find one positive thread about Synchron Strings.  Now, what is being "swept under the rug"?  Nothing ever prevented you from posting a new thread with a title to put the attention on the problems you want brought to light.  Derailing this thread did nothing but frustrate professional users who only wanted to talk about something besides bugs. 

Right.  Then discuss, but no need to counter someone's opinion just because they offered one you disagree with.   

This is why forums aren't considered viable places for discussion for many of us - "how a forum works" currently isn't how constructive, respectful dialogue works.  That is one reason I (and most of my colleagues that I know of) don't spend much time on forums anymore;  also simply too busy.  And here I am being reminded why I don't usually post on forums. Back to work.

Congrats to VSL on Synchron!  Love the stage too - hope to record there at some point. 

If you respect others opinions, then let the OP have his thread.  I don't see why that would be a problem. It would be more productive to post complaints in a separate thread anyway as it is easier for developers to read and respond. 

Unfortunately, this seems common, especially with composers.  It is one reason I don't participate at most composer forums anymore.  I, for one, was glad to see your enthusiastic post.  I am very optimistic about Synchron Strings, and any future Synchron products.

There is no reason for people to hijack a positive thread.  They could easily start a new one, and should.  Enjoy Synchron, I know I am.  It has already made its way into my current film score.  

No, the articulations single-sections analogy isn't valid here - two very different tradeoffs. 

Of course the point of multi-mic is to provide options, but it doesn't mean you can't or shouldn't use a single mic if needed, or if multiple mics simply are not necessary.   I'm not sure what you are suggesting VSL give up to allow you to run all articulations and mics.  Velocity layers make a noticeable difference when using velocity crossfade via cc fader.  How much RAM are you trying to fit this into?

I would think anyone buying libraries with these options would be well aware of the need to configure systems, and mixing options, to make use of them, or be willing to compromise.  Surely users don't think they can run a full Synchron orchestra template on a 32G, or even 64G PC with all mic options.  I wouldn't consider building a new system with less than 128G at this point, even before Synchron. 

Fwiw, OT's Berlin strings work fine with a single mic, if you use the right one, or have the score mixed by a score mixer (done that before).  What sounds good "out of the box" doesn't necessarily work as well in a mix, especially with other libraries in a complex score, at least when these are not just for mockup reference. 

To bring something positive back to this thread - Synchron is a new standard, at the very least for the surround/Atmos options. Every library requires some work and skill to get convincing results, if you write for the music instead of the samples.  There isn't much VSL, EW, OT, Spitfire or anyone else can do to change that. 

The simple solution is to use a single mic position - sure, not ideal, especially if you are going for an Atmos mix, but this is really no different from any other multi-mic library.  I played around with the different mic options, and the Room mix, and found the Main L+R to be just fine, and easier to pan wider to fit with my mix and other libraries.  Disclaimer here - I typically take a single mic and mix my own templates anyway to fit the overall sound I am going for, and I've spent a lot of time finding the best ways to do this.  I know for users who want to pull up all mic positions and have the "out of the box" mix options available, yes, you need more RAM.  That's the tradeoff - more options require more resources. 

I have the full Synchron library, with all cells active, all articulations, single mic position, loaded with my template and all other sections on my host PC within 64G of RAM (several SSDs for streaming), no problem.  It is easier to mix a single mic position with other libraries; and it is easier to write with all arts than trying to fake a missing articulation.

I understand your point and sure, it is nice to have a little more natural attack.  However, coming from using several other major string libraries, I have to disagree in general.  Inconsistent shorts (attacks, levels, and even lengths) is frustratingly time-consuming in some other libraries - the best/most used libraries, not the inexpensive smaller libs.   Round robins that vary 3-6db in volume made some patches in my main string library unusable.  Inconsistent short attacks frequently require extensive editing to a cue to fix poor timing, and some patches, again, are completely unusable because those attacks aren't consistent from layer to layer, note to note. 

I am new to VSL libraries (having used VEPro for years, but never their libraries), and I can say without a doubt the accuracy is going to save a lot of time with mockups.  The shorts have already replaced another library in the cue I am working on at the moment. 

As far as legato complaints, there always seem to be tradeoffs.  The best library I have, and have used for easily playable legatos suffers from too much slur.  So, while they sound great sometimes (if not overly romantic most of the time), they have to be dialed back or note-to-note transitions edited to avoid the legato transition altogether.  Synchron will require a different approach I think, but I am already hoping to see legatos in Violins 2 and Violas in some update (Synchron 2?).

Personally, I am quite happy with Synchron Strings 1 as a solid starting point for the series.  It is an excellent string library, and I don't get paid to say so. 

Hi Dietz,

Yes, Windows 8.1.  Multiband Pro is version 2.0. 

This seems to be an isolated occurence.  I could not reproduce it in either Nuendo 7 or a blank project in Cubase 9.5. The crash was in a copy of a score mastering project I have been using to test Suite Pro.  I will send the crash dump to Steinberg and see what they say.  It may be related to something else in Cubase 9.5.

Overall, these plugins are excellent, and very stable (ASIO load is very stable with multiple instances, which is always a good sign).   I plan to upgrade to Pro at some point. 

With the Multiband Limiter Pro (VST3) set to manual, using ctrl-click to delete a node in the attack envelope will consistently cause a "serious error" and crash dump in Cubase 9.5.  It does not completely crash Cubase, or even stop playback.  This is contained error within Cubase that does not affect operation.  These errors can corrupt a project, though it doesn't seem likely in this case.  This is the demo version of Vienna Suite Pro, and a test project. 

The VST2 version does not create a crash when deleting attack envelope nodes. 

Absolutely.  I had been getting frequent timeouts ("operation failed") errors when trying to refresh the number of starts for the Vienna Suite/Pro demo license and as a part of troubleshooting that, updated eLicenser and ran maintenance, etc (VEPro must be closed when using eLicenser, which takes time to reload with large templates). 

You are right - thank you. 

The first times I tried the VST2 version a couple of days ago, I got an eLicenser error (not licensed to run), though the license was clearly active.  I thought it was the demo license running out of starts and after going through some hassles with elc trying to refresh the license, I never tried the VST2 version again. 

I had the same elc error when I first loaded the vst2 version just now, but after saving the project, closing Cubase and reopening, it is loading without crashing (and without the elc error, for now at least). 

I will test the VST2 version a bit more, but it does seem to be unaffected here as well. 

Thank you Dietz!  I appreciate the help and quick confirmation.  I will check back in from time to time to see if a fix is posted to updates. 

Windows 8.1.  This is an i7 PC, 64G Ram, SSDs, etc.  

Hybrid Reverb will crash even a basic blank project with nothing but one FX bus with one instance of Hybrid Reverb.  Once Cubase is closed, that project will crash as long as Hybrid Reverb is availble to load (I have to remove it from the VST3 folder to open those projects). 

Yesterday only a latency of 128 seemed to work, but today it is back to 512, or so it seems. There may be some sequence of "default" vs. saved presets vs. saving a project with unsaved Hybrid Rev settings that contributes to when 512 works or doesn't.  But regardless, it will crash at any other setting, and often with 512 as well. 

Pro works fine, so something was changed in the Pro version vs. the standard version that fixes this.

I have a crash dump from one of my tests just now with Cubase 9.5 that I will send to Steinberg, but it will likely be a couple of weeks before they are back from the holidays to check it.