@Michael Canavan said:

One thing, IMO it's a travesty and poor business move that they did not release Apple silicon native versions of the VST, MAS, and AU VEP plug in at the least. This wouldn't require low level code etc. and would make it possible for Cubase users to actually use their DAW along with an Intel PC or Mac server, or even VEP in Rosetta using the native VST in Cubase. I can't think of a rational excuse this didn't happen. 

I agree, I just need the bridge plug-in.  Nothing else.  VSL can take all the time they want to make the server application M1 Native as far as I'm concerned.  Although, I understand other people need that more than I do.  But I feel like people would be more forgiving if they released the bridge plugin and then said, okay it's gonna be another 6 months for us to re-code the server application.  At least then, we would have a work around.

hi all,

as much as i would like to get more libs, i will not do so till M1 support is working with VSL.

This must be the last, and most expensive app i have, which has not made the transition yet.

i find myself spending a lot of time on the spitfire site...

@Michael Canavan said:

One thing, IMO it's a travesty and poor business move that they did not release Apple silicon native versions of the VST, MAS, and AU VEP plug in at the least. This wouldn't require low level code etc. and would make it possible for Cubase users to actually use their DAW along with an Intel PC or Mac server, or even VEP in Rosetta using the native VST in Cubase. I can't think of a rational excuse this didn't happen. 

So much this. This. I think they feel that they have to release it, synchron and MIR all in one go. This plug-in update alone would make a lot of the difference, especially to Cubendo users. And even saying what year they anticipate the server side to be ready in.  If they can't say the year with confidence then we're looking at "not even close and may never actually happen" as the most reasonable assumption.

I can feel it in the air, they're working on it! 

I cannot complain about any music software companies as I am certain of their willingness to do things right but I think this unacceptable delay in releasing a M1 version of VEPRO or other plugins is likely due to a lack of technical or financial resources. VEPRO is a sizeable investment and an amazing product : it saved me a lot of time in my projects, connecting my VSTs with my notation software Dorico.

But I have a beast of an Apple Silicon MacBook Pro with universal DAW and Notation Software working so well on huge projects so I cannot wait any longer. I decided to change my Apple Silicon setup and found a way not to have to use VEPRO anymore. This is a pity. And VSL is not the only company creating these situations : I had to drop my amazing Altiverb plug-in because it is still not Apple Silicon Native after years. Same type of vague communication.

What surprises me is that it seems to me that no company commited themselve about a particular deadline. I have been told when  was young that the waiting was far more acceptable when you knew how long you will have to wait.

@FranckD said:

I had to drop my amazing Altiverb plug-in because it is still not Apple Silicon Native after years. Same type of vague communication.

You may not have to drop Altiverb. I've been using AudioGridder 1.2.0 (Beta 15) for months now, it allows me to use Altiverb on a farm computer. In some ways (and for that particular application), it's been more useful than VEPro 7 was. I too eagerly await a silicon native version of VEPro, but having a very busy work schedule, could no longer afford the wait. AudioGridder has allowed me to keep working sans VEPro.

@FranckD said:

I had to drop my amazing Altiverb plug-in because it is still not Apple Silicon Native after years. Same type of vague communication.

You may not have to drop Altiverb. I've been using AudioGridder 1.2.0 (Beta 15) for months now, it allows me to use Altiverb on a farm computer. In some ways (and for that particular application), it's been more useful than VEPro 7 was. I too eagerly await a silicon native version of VEPro, but having a very busy work schedule, could no longer afford the wait. AudioGridder has allowed me to keep working sans VEPro.

I'm curious, are both of you using Cubase? I'm annoyed and waiting for the native version for sure, but because the Rosetta AU version is limited tracks wise and I'm waiting on the MAS and VST3 versions for larger templates. For most work though the Rosetta AU works here, barring a few GUI glitches! 

@loufeb said:

I'm curious, are both of you using Cubase? I'm annoyed and waiting for the native version for sure, but because the Rosetta AU version is limited tracks wise and I'm waiting on the MAS and VST3 versions for larger templates. For most work though the Rosetta AU works here, barring a few GUI glitches! 

I use Cubase 12, in Silicon Native mode. Mac Studio M1 Max (Mac Pro 2013 and Mac mini 2018, both 64GB, as farms.

Had a session this weekend, couldn't drop below 512 buffer size without VEP crashing Cubase.  Even though I've got plenty of CPU headroom.

Really wish they would release the bridge plugin....

It's been 2 years and 3 months since M1 was publicly available.  Not counting the DTK.

[/quote]

 "You may not have to drop Altiverb. I've been using AudioGridder 1.2.0 (Beta 15) for months now, it allows me to use Altiverb on a farm computer. In some ways (and for that particular application), it's been more useful than VEPro 7 was. I too eagerly await a silicon native version of VEPro, but having a very busy work schedule, could no longer afford the wait. AudioGridder has allowed me to keep working sans VEPro."

[/quote]

Hi ! Thank you very much for the tip. I installed it but deinstalled it immediately as I am not confortable with the software policy : non recognised developper and requirement to access to my documents, to record my audio and my screen. This is a usually a NoGo for me.

@FranckD said:

Hi ! Thank you very much for the tip. I installed it but deinstalled it immediately as I am not confortable with the software policy : non recognised developper and requirement to access to my documents, to record my audio and my screen. This is a usually a NoGo for me.

[/quote]

I understand you concerns completely. For me, AudioGridder replaced VEPro and allowed me to keep working, but your concerns are very valid.

@Michael Canavan said:

The problem here is conjecture. You're just as guilty of it as anyone who thinks that VSL don't have good reasons to have put Apple Silicon first in terms of support. You do not know why and neither do we.

I dropped VEP for good 2 months ago, now working with a "disabled track"-template. Best decision I've ever made.

Before dropping, I used disabled tracks, where Keyboard Maestro was translating a keyboard shortcut into enabling/disabling tracks via MIDI inside VEP, thinking that VEP was more CPU efficient.

It isn't. After removing that, I've seen about 20% CPU reduction in Rosetta and my iMac Pro Intel mac, even more when using Silicon Native on my Mac Studio M1 Max Ultra.

Running VEP localhost instead of hosting plugins inside the DAW is no longer the better option. The macOS version beyond iLok transition is not stable enough, and it uses more system resources. At least on my two systems.

I've used VEP for 10 years. It was a big step leaving it behind, but no regerets here. Using Nuendo 12 and macOS 12.6.

I've got three servers running on VE pro that I am seriously considering retiring in order to run the same "disabled track" template you are talking about. Before I commit to a very large task of re-creating my whole template, do you have any advice or warnings for someone in a similar scenario who is about to do the same thing?

Oh, and have you solved the issue of RAM not going back down after disabling?  I'm slightly concerned about this as well.  Sounds like I'm not the only one:

https://forums.steinberg.net/t/hi-timo-question-about-ram-dumping/64236/18

Hi,

just to share my latest experiment to replace VEPRO in my Dorico setup combining IAC Manager & Mainstage of Apple. Here what I have succeeded to do :

STEP 1  - CREATE A MIDI BRIDGE

1. I opened "Midi and Audio configuration" on my Mac
2. I opened the Midi Tab & selected IAC Manager
3. I activated the IAC Manager & created a new port called "String Spitfire"

At this stage, in Dorico after restart I can now see a new Midi output "IAC String Sptifire" where I can route my Violins I on channel 1, Violins II on channel 2, Violas on channel 3, etc. IMPORTANT : you need to desactivate in Dorico Preference midi Input of IAC to avoid midi loops.

STEP 2 - CREATE A SERVER

1. I opened Mainstage, created a new patch called "String Spitfire" with 5 channels
2. I allocated each channel to a Kontakt instruments (reps. Violins 1, Violins 2, &hellip😉, and modified the channel input of each (Violin 1:1, Violin 2:2, Violas:3,…)
3. Then, in the Channel Strip inspector at the bottom, I have selected « IAC String Sptifire » as a Midi input

And Voilà ! Now my strings in Dorico are connected to the Spitfire Strings in Mainstage. Tomorrow I will try to repeat the process to create Spitfire Brass,  Spitfire Woodwind and all the libraries I have creating new patches.

This solution is very promising and hope I will be able to create and connect my brass as well. I will keep you updated.

EDIT 1 : it does not work, my mistake : you can play only one patch at a time. So the server should be created in Logic Pro  or cubase

EDIT 2 : Finally it can work but you have to add keyboards to the current patch, assign this new keyboard to IAC Spitfire Brass and assign you instrument Kontakt to this new keyboard. So you can create as many IAC port as you have libraries, and route you DAW/ notation software to the corresponding bus of the library you want to use. This way you can load a projet instantenously as all instruments are preloaded in your Mainstage

Hi everybody,

Time to open a new chapter, in a new thread!

Best,
Paul

@Eric Owyoung said:

I've got three servers running on VE pro that I am seriously considering retiring in order to run the same "disabled track" template you are talking about. Before I commit to a very large task of re-creating my whole template, do you have any advice or warnings for someone in a similar scenario who is about to do the same thing?

Oh, and have you solved the issue of RAM not going back down after disabling?  I'm slightly concerned about this as well.  Sounds like I'm not the only one:

https://forums.steinberg.net/t/hi-timo-question-about-ram-dumping/64236/18

There are an endless ways of designing Disable Track-template, but it has vast advantages compared to having everything loaded IMO. The most important thing would be that you have a cleaner project visually, with the advantage of still having all the bus routing and signal chains intact. When I start my template it's completely empty. Using different Project Logical Editor chains and Keyboard macros within Cubendo, you can create show/hide-presets for just about anything.

If you're going to transfer things from VEP, then get Keyboard Maestro and make macros for everything (saving Kontakt multis, etc). VEP to me has always been "half-finished" when it comes to workflow. Things that should have shortcuts doesn't, or it crashes when using the shortcuts, or text elements (track names, etc) randomly stops responding to keyboard shortcuts, so they need right-click-menus to be copy pasted to/from. All these repetitive tasks can break you down, it's better to use KM to record a macro that clicks for you. It takes some time setting up, but defenitely worth it.

The "purge RAM"-issue I haven't noticed any problems with, but I have 128GB RAM in both my workstations, so plenty of headroom.

@Paul said:

Hi everybody, 

Time to open a new chapter, in a new thread!

Best, 
Paul

Hey no disrespect meant, but it was mentioned that VEP was in beta months ago, so it's great that Synchron is AS and all, but anyone who thought about it from a business perspective knew that VEP would not be first to port, since then you would be showcasing Kontakt, Play, Spitfire libraries native AS support while highlighting inadvertently that Synchron etc. were not AS compatible yet. 

 So great news, not sure how it relates to this thread in general? since it's still months away from native support, just now with an offical announcement. 😊