To be honest, I just hope that the plugins can be Apple Silicon native, so that I can finally stop running Cubase in Rosetta mode and take full advantage of the powerful Mac Studio. The server software itself can stay as it is, since most people I know run their sample rigs on Intel-based machines (Windows or Mac). One can dream...

I have no doubt that people at VSL are working hard on it. But I hope that they also understand why their customers are frustrated and disappointed after such a long wait. Many pros have spent a lot of money on the Mac Studios (or even the new MacBook Pros), yet we have to keep running our DAWs in Rosetta because of VE Pro.

I believe it genuinely is incoming - or at least VST3 support within VEPro as Paul on this thread suggests...

https://www.vsl.co.at/community/posts/t59610-Kontakt-6-and-7

VST3 support is here. It really feels like Christmas morning here. I truly hope that it means Apple Silicon support is coming in the near future.

Has anyone tried running VEPRO as AU inside the Bluecat's Patchwork wrapper?  MIR3D works well here in Cubase 12 / Silicon mode that way.

@Watercolor Music said:

VST3 support is here. It really feels like Christmas morning here. I truly hope that it means Apple Silicon support is coming in the near future.

Not seeing this anywhere. 

@Watercolor Music said:

VST3 support is here. It really feels like Christmas morning here. I truly hope that it means Apple Silicon support is coming in the near future.

@Watercolor Music said:

VST3 support is here. It really feels like Christmas morning here. I truly hope that it means Apple Silicon support is coming in the near future.

Thanks Dan, that's great! Supposedly VST3 is better at releasing CPU back to the host so over the years here it should be a better choice for plug ins in VEP servers. Plus it means VSL are done mucking with it and can get busy on putting the Apple Silicon beta through it's paces. My and I imagine your big fear, is they do not port the MAS version, so I wait with baited breath. 

I think I'm ready to spend all my money on a maxed out M2Max MBPro 16", maybe in a month or so. Which means I'll be checking in here quite a bit also 😃 And yes, begging for a MAS version 😝 That laptop and my current iMac Pro as a slave should be all I need forever and ever 😎 . Ok, maybe I'll wait til March to check back in here. 😊

It's my understanding that the reason VEPro works is low-level code, directly addressing hardware - which when it was originally written was Intel.  Now that Apple Silicon is here, and it's a completely different hardware platform and architecture, it's got to be like writing the whole thing from zero.  Maybe the M-series CPU's don't deal with these direct calls as well.  That's all beyond me.  But I think of this like a team of developers writing an entirely new app that has the goal of enterprise-level reliability and the greatest efficiency and speed possible.  How long would one say that should take?  Especially if they have other things that people are clamoring for.

Some folks are acting like the folks at Vienna don't care about users' feelings about this.  Of course they do.  But they can't do anything about those big feelings except put out the best product they can, and for our part we can maybe not act like our feelings trump reality.

@dragsquares said:

It's my understanding that the reason VEPro works is low-level code, directly addressing hardware - which when it was originally written was Intel.  Now that Apple Silicon is here, and it's a completely different hardware platform and architecture, it's got to be like writing the whole thing from zero.  Maybe the M-series CPU's don't deal with these direct calls as well.  That's all beyond me.  But I think of this like a team of developers writing an entirely new app that has the goal of enterprise-level reliability and the greatest efficiency and speed possible.  How long would one say that should take?  Especially if they have other things that people are clamoring for.

Some folks are acting like the folks at Vienna don't care about users' feelings about this.  Of course they do.  But they can't do anything about those big feelings except put out the best product they can, and for our part we can maybe not act like our feelings trump reality.

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.

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. 

@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.