I agree, this seems to be just a matter of VEPro timing out its initial broadcast while initializing/scanning plugins.  I just started VEP server to test, with a single blank instance, and started Nuendo 12 at the same time.  By the time N12 was open and I added a VEP instrument, the instance appeared.  

As VonMuse suggested, clicking on/off "Advertise on local network" is a simple workaround, if this happens.  So far, it has only happened during the initial VST3 scan that took several minutes. 

Hi Paul,

This is on a i7 PC, Windows 10.  The host is Nuendo 12, and VEPro 7.2 is running on the same system.
It only happened the first time I tried to connect, after VEP/server sat a while waiting for me to confirm two plugin failures during the scan.  I checked the plugin version in Nuendo to be sure I wasn't loading an old version from a different VST folder, and it was the latest (7.0.1481). 

Probably just a one time rare occurance.  If someone else runs into it, a simple restart of VEPro seems to solve it, but I somewhat doubt it will show up again.

Other than that one little oddity, 7.2.1481 is running smoothly on the i7!

I updated to VEP 7.2.1481 to check VST3 compatibility, and VEP server scans plugins and starts fine (took forever to scan VST3).

However, when loading a VEP plugin in Nuendo the first time, it did not see the server - no instances appeared in the plugin connect display.   I had to restart the server for Nuendo to see it. 

Could it be that the VST3 scan process took too long and either the local network connection timed out or the broadcast never initialized?   I left the initial VST3 scan running and came back later to acknowledge a couple of blacklisted plugins, so it did sit between scan and final load for a while.

Just an fyi. 

Originally Posted by: toodamnhip

This is the REAL #1 issue users need addressed. I believe it can be done. It starts with a no excuses attitude and THREE- realizations:

1) that VE Pro is extremely vulnerable.

2) That it is completely unacceptable for any one malfunction of a VI to stop the entire template from loading. 

3) That something CAN be done about it.

Ditto to all of the above.  Because of VSL's glacial move into the Mac M1, M2 and now M3 era, I had to drop VEPro as a server, move to ipMidi and hardware I/O and am only using VEPro as a standalone host.   But..... it freezes/simply stops responding to input frequently.  It is only running EW Play, Synchron and Kontakt 6. That's it.  No mixing of other VIs - just those three.   It also crashes constantly on an i9 Win11 server I've been wanting to integrate into my setup, but had to give up.  VEPro is not stable enough for demanding work.

I finally had to drop VEPro for the foreseeable future.

I spent the past 4-5 weeks, between projects, working out an alternative to VEPro on the M1 so I can run DP natively, and I've settled on ipMidi and hardware I/O (VEPro or Cantabile hosting on the slave PC).  ipMidi is limited to 20 ports, but is far easier to setup and use than RTPmidi.  

I'll see what the new year brings from VSL, but I simply could not wait any longer, and had to find a long term, reliable solution due to a heavy workload next year that I need to start preparing for now.  

It is worth it just to run DP natively (significantly better performance vs DP-Rosetta).  I also can't assume the next version of VEPro will be stable enough for demanding work out of the gate.  It could be months before VEPro-native is an option, if the MAS plugin is even available upon first release.  

This took a lot of time to reconfigure and test, and time is money.  It also comes with a significant hardware investment for the necessary I/O.  I know it is "old school", but it works very well.  

I see you already solved this, but fwiw, I have both a Windows 10 and a Windows 11 slave working with my M1 Macbook Pro (VEP in Digital Performer under Rosetta).  I did not set static IP addresses as I have all three running into a 10G switch, then a router that connects to our home network.   Static should work fine as well, as long as you turn off or configure the firewall (I always turn off all of Windows' security - Defender, firewall, etc for sample servers and audio work in general).  

Originally Posted by: Michael Canavan

I'm running DP11 in native Apple Silicon mode, the issue isn't that you have to run your DAW in Rosetta it's that you have to run the VEP plug in, in AU, so no VST or MAS version for instance,

Ditto - All I need is the VEP plugin to be M1 native (MAS preferably). All of my servers are PCs.  I have no plans to run VEP server on a Mac M1 anytime in the next 1-2 years. 

Check which version of VEPro you are running.  If it is the latest, try rolling back to 7.1.1298.  There is a bug with the latest that causes VEP to add blank instances instead of connecting to the correct one. 

Originally Posted by: ariacat

It's time VSL offer everyone unlimited free licenses to run its ancient VEP software on as many external machines as they want so that we can put all the VSL stuff on those old Intel computers we have lying around while running native M1 DAW software on our new Mac Studios. 

I agree.  I typically try to keep my expectations from companies fair to them as well as customers, but VSL prioritizing stopping a few 14-year olds from using their software illegally (iLok), ahead of thousands of working, paying professional customers is a step too far.  I put up with iLok, but it costs users quite a bit more than it saves developers (I ran the numbers in my own case over the course of a year;  developers have no similar data and can only rely on speculation). 

It seems reasonable to suggest that VSL offer an olive branch to its paying customers.  I understand this may have been an unfortunate collision of circumstances for VSL - end of elicenser just before the release of M1s.  But I also know this has cost me many hours and late nights trying to create workarounds, with little success, as it has others.  Even if VSL releases an update next week, this situation makes me question the wisdom in relying on VEPro.  For that reason, I am very close to committing to a return to hardware audio and Midi I/O and one of several instrument hosting options to eliminate any further VEP hassles permanently.  The only obstacle there is cost.  It is much more OS/upgrade future-proof than software such as VEP. 

As much as I like VEPro, it is a risk.  Future hardware and OS updates could put us in a similar situation, and this includes Windows.  Win 11 is already a security-obsessed nightmare. 

Which version of VEP 7?  I have Opus running on a Windows 11 machine with 7.1.1298 and the same patch looks fine (shows as Hollywood Strings, mood settings work, etc). 

Originally Posted by: Jon Newton

...except when I did the rollback, it removed the VEP plug in from the Library > Audio > Plug-ins folder, and now it doesn't work at all in Digital Performer...

Are you running VEP server locally on the same Mac as DP?  In my case, it was a slave PC that I had to rollback.  That only affected VEP server.   My Mac M1 is running an older version of the plugin itself (7.0.1120).  Both PCs are 7.1.1298.  That setup works, at least with DP.  Nuendo 12 doesn't work well under Rosetta with VEP plugins. 

Originally Posted by: Karmand

WHY?

I just did the upgrade when prompted to update VEP7

I had the same thing happen yesterday with a new i9 slave PC, and new install of VEPro 7.1.1427. 

Roll back to 7.1.1298 and that should fix the problem.  There seems to be a bug in .1427 that causes VEP server to create a new instance instead of connecting to existing instances.  In my case, the new instance truncated the first 4 characters of the name of the instance I was trying to connect to (i.e. connecting to "Strings" would create a new instance named "ngs").  Using the new instances will not work - reloading a project and reconnecting to VEP will just cause VEP to create more new instances. 

Use the rollback feature in the VSL Assistant - in the Vienna Ensemble Pro install icon, under the version, click the three dots - at the bottom is "rollback" and you can select the version to roll back to. 

I setup an i9 sample server last night, and the latest version of VEPro (7.1.1427), and can confirm it has serious bugs.  In my case, connecting from the main host (M1 Mac), caused VEP on the i9 to create a new instance with a truncated name.  If the original instance I connected to was named "Strings", the new instance would be "ngs".  I couldn't simply use the new instance.  Saving and reopening a project caused the same bug - connections would create a new blank instance and connect to that.  

I have an i7 server working fine with VEP 7.1.1298, so I rolled VEP on the i9 back to .1298 and it now works fine.  Both servers are connected.  I would withdraw 7.1.1427 from VSL's downloads and installer. 

Out of curiosity if this is of interest to anyone new to DP on M1, I just tested DP running VEP AU (DP Native) vs MAS (DP in Rosetta) using my full scoring template, with video attached.  

1 - DP in Rosetta, VEP MAS:

• Pros: much lower Real time processing load/cpu usage, with the advantage of having multiple midi ports per instance.
• Cons:  GUI is somewhat less responsive, or less smooth.  Noticeable graphics anomalies when changing tabs.

2 - DP Native, VEP AU:

• Pros:  DP runs very smoothly. GUI is quick and responsive. Excellent user experience by comparison.
• Cons:  Higher real time processing/cpu load with VEP in AU format (DP's load without VEP instances is minimal).  Only a single midi port per VEP instance. 

So, those are our options.  I am moving my scoring work to DP, and have an M1 Mac sitting here waiting, with scoring projects coming very soon.  DP simply does not run well enough on Windows (my i7 at least), to be usable (GUI is way too slow).  That leaves very few options.  

We really need native compatibility for VEPro MAS ASAP.  AU isn't a viable option for me and probably many other DP users.  Note that DP was native compatible not long after the first M1s were released.  It was native at least in November of 2020 - two years ago.  MOTU may have been better positioned to make the transition quickly, but if they can do it, others could have as well. To be honest, copy protection is only for the benefit of the developer (again DP's simple system is a good example).  It should never get in the way of customers or our work.  

VSL - we are at the point even a rough timeframe for native compatibility is better than nothing.  Many of us are having to consider costly alternatives to VSL and VEPro that, given the reality of our schedules, won't be temporary.  That could mean lost sales for VSL in the future, and probably already has for customers new to VEPro and VSL.  

Originally Posted by: bdr

are there any realistic alternatives?? The lack of urgency is intolerable.

When I have time I am working through configuring Cantabile to run as the host on my i7 with RTP midi to connect to DP on my Mac M1.  That's my longterm plan.  The downside is being more limited on audio streaming back using hardware I/O.  But the upside is that is very stable.  I've been running an older i7 slave this way for years.  

This probably won't work for some, but it is an option, and one I know works well now. 

I am considering moving my sample hosting to Cantabile for this reason.  I already have a 128G server at the studio with Cantabile hosting, and it works extremely well - quite possibly lower cpu usage than VEPro.   I/O is limited to hardware, but I've done this with another sample server for years.  It may take a while for a stable version even after an M1 native release.  I could be wrong, but it really is impossible to wait this out and let the M1s sit idle.   Thing is, once I make the move, I won't likely revert back to VEPro anytime soon.  

Adding another plea for an M1-compatible VEP plugin, above all else.  It really doesn't matter what new libraries come out if we can't access them with VEPro. 

Now that the iLok transition is done, and we all spent hours reinstalling VSL libraries to accommodate VSL's change, please give us customers something in return- access to them through VEPro on M1 Macs.  PCs run all of my libraries in VEPro, and will for years to come.  The server can wait.  The plugin is long overdue. 

I have heard the same problem here - Elite Strings mostly, but I've heard it in Synchron Pro as well.  It happens mostly when using Vibrato XFades, even with a single mic.  It sounds like the transitions are not phase aligned to one another.   It is very audible and has severely limited how much I can use Elite/Synchron Pro vs other string libraries. 

I came here to search for and inquire about exactly this scenario - an M1 running the host sequencer, with VEPro on high-RAM slaves.   All we need is the VEP plugin to work (MAS for me, AU for others). 

I am considering adding an M1 for exactly this purpose, but if native support is months away for VEPro plugins (server can wait), I might not get an M1 and add another slave instead.

Originally Posted by: Michael Canavan

 One thing that's missing from this conversation in general is this. It would be absolutely fantastic to get the plug in VEP in VST, MAS, AU etc. ported to Apple Silicon first. this seem entirely possible and solves a major issue with Apple Silicon Macs in general, i.e. you could run your DAW (well most DAWs at this point anyway), in native and host x86 plug ins on a VEP server on an older Mac or PC. 

I ran into this years ago with Kontakt, but finding it a significant problem with VSL Elite and Synchron Strings in Synchron player.  I assume this is baked into the player's time-stretching. In the past, turning of tempo sync in Kontakt was the workaround, but I can't find a way to do this in Synchron.  The only tempo sync option I can find (Edit - Stretch) is already off.  I have customized all of my Elite Strings and Synchron Strings presets with the included reverb off, so that isn't the culprit. It is the dry samples distorting. 

Nuendo 11 - ramped tempo changes cause distorted playback.  Stepped is fine, but a very cumbersome, and inadequate workaround.

Studio One 5 - bezier curve tempo changes are fine, though probably sending stepped changes while using a curve-based graphical representation - still light years better than Nuendo. 

Digital Performer 10 - uses stepped tempo changes when drawing curves, so no distortion problems Synchron instruments. 

With Soft Release, the tails will last longer by design.   If that is the desired effect, then you have to allow time for the tail to decay to sound natural.

For quicker articulation changes use Normal Release.  Even with CC 23/Release at the default, a Normal Release long note (Senza, etc) will not decay into the next Pizzicato note at a medium tempo, 1-2 beat delay between notes.  If needed, then you can lower CC23/Release slightly if you need a quicker cutoff for the Long notes. 

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.