Hey Urs,
Now that Ableton Live has come out with a 64 bit beta, I'm eager to start using it, however a couple of my favorite plug-ins still need 64 bit versions for VST - Diva and Zebra.
Any idea about when these will be available? I only enable my VSTs so don't use AUs.
Many thanks!
64 bit Mac VST timeline?
-
Echoes in the Attic Echoes in the Attic https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=180417
- KVRAF
- 12036 posts since 12 May, 2008
-
- u-he
- 30194 posts since 8 Aug, 2002 from Berlin
Does Live support VST3 yet?
I'd recommend using the AUs in Live - those have been 64 bit for years.
We only bother with VST3 to get 64 bit support into Steinberg's offerings on Mac.
I'd recommend using the AUs in Live - those have been 64 bit for years.
We only bother with VST3 to get 64 bit support into Steinberg's offerings on Mac.
-
- u-he
- 30194 posts since 8 Aug, 2002 from Berlin
Note: We will not support VST2 for 64 bit on Mac. We can't do our bundles because of Cocoa name space collisions. The only workaround for us clashes with code signing for Mountain Lion.
-
Echoes in the Attic Echoes in the Attic https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=180417
- KVRAF
- Topic Starter
- 12036 posts since 12 May, 2008
Damn. That's the worst news I've heard all day.Urs wrote:Note: We will not support VST2 for 64 bit on Mac. We can't do our bundles because of Cocoa name space collisions. The only workaround for us clashes with code signing for Mountain Lion.
I have never found a single reason to use AUs in Ableton Live on my Mac, but I've found a good half dozen strong reasons to use VST. And I've rather just use one so that I can disable the other.
I see no sign of Ableton supporting VST3 any time soon. Are Zebra and Diva already VST3 64bit? I could live without Zebra for a while but not Diva!
-
- u-he
- 30194 posts since 8 Aug, 2002 from Berlin
-
- KVRian
- 1216 posts since 6 Jul, 2005
The u-he AU versions don't update controller parameters between patches (like the VST ones do)... making it very hard to use in a live situation.
(BTW... you were talking about trying a workaround to get this to work in the AUs).
(BTW... you were talking about trying a workaround to get this to work in the AUs).
-
Echoes in the Attic Echoes in the Attic https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=180417
- KVRAF
- Topic Starter
- 12036 posts since 12 May, 2008
The things I don't like about AU are:
-AU have no midi output but VST does.
-Projects can be shared between Mac and PC that use the same plug-ins if they are VST.
-VST is absolutely crucial to using Novation automap, which is by far the best mapping system to ever come to hardware. With AUs, it creates a single separate automap AU. If you remove automap from your computer, the automap AUs can not be found. It can not be replaced by the regular AUs. With automapped VSTs, it makes a wrapper for each plug-in that references the original. What happens when you remove automap from your computer when you have automapped VSTs in your projects? Nothing. The regular VSTs load up fine with all their settings intact. In fact, you can even start using automap and create the wrapped versions and all your old projects will let show as the automapped VSTs version. In other, totally interchangeable. So if you're ever worried about stability and want to temporarily remove the automap version, you just move them out of your folder and use the normal ones for a show and put them back after. AUs are simply not usable with automap if you want to not be tied down forever to that format.
-I like the fxp preset format (easy switching in Ableton devices with arrows etc.). I do not like the aupreset format. fxp/fxb always transferable between mac and PC. aupresets also can't be used with automap because it sees it as a different plug-in. fxb are fine with automap.
-I've often found VST versions to be less buggy as well, usually due to devs having done the VST first for Windows compatibility and then porting (I know this wasn't the case with u-he stuff though).
There are other reasons I'm forgetting as well, but those are the most important. While I could mix and match, I prefer to only have the plug-ins active of one type. VST has done me well, no looking back. The only reason I've seen so far to use AU is u-he synths. However, I think JBridge in Ableton will be the way to go instead to use your plug-ins as 32 bit VST in Ableton 64.
-AU have no midi output but VST does.
-Projects can be shared between Mac and PC that use the same plug-ins if they are VST.
-VST is absolutely crucial to using Novation automap, which is by far the best mapping system to ever come to hardware. With AUs, it creates a single separate automap AU. If you remove automap from your computer, the automap AUs can not be found. It can not be replaced by the regular AUs. With automapped VSTs, it makes a wrapper for each plug-in that references the original. What happens when you remove automap from your computer when you have automapped VSTs in your projects? Nothing. The regular VSTs load up fine with all their settings intact. In fact, you can even start using automap and create the wrapped versions and all your old projects will let show as the automapped VSTs version. In other, totally interchangeable. So if you're ever worried about stability and want to temporarily remove the automap version, you just move them out of your folder and use the normal ones for a show and put them back after. AUs are simply not usable with automap if you want to not be tied down forever to that format.
-I like the fxp preset format (easy switching in Ableton devices with arrows etc.). I do not like the aupreset format. fxp/fxb always transferable between mac and PC. aupresets also can't be used with automap because it sees it as a different plug-in. fxb are fine with automap.
-I've often found VST versions to be less buggy as well, usually due to devs having done the VST first for Windows compatibility and then porting (I know this wasn't the case with u-he stuff though).
There are other reasons I'm forgetting as well, but those are the most important. While I could mix and match, I prefer to only have the plug-ins active of one type. VST has done me well, no looking back. The only reason I've seen so far to use AU is u-he synths. However, I think JBridge in Ableton will be the way to go instead to use your plug-ins as 32 bit VST in Ableton 64.
-
Echoes in the Attic Echoes in the Attic https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=180417
- KVRAF
- Topic Starter
- 12036 posts since 12 May, 2008
Yep, that too. That's enough to make me not use the AU versions of Zebra/Diva.taoyoyo wrote:The u-he AU versions don't update controller parameters between patches (like the VST ones do)... making it very hard to use in a live situation.
(BTW... you were talking about trying a workaround to get this to work in the AUs).
-
- u-he
- 30194 posts since 8 Aug, 2002 from Berlin
I'm sorry but I can't help you there. We might be able to workaround Automap (bought a few Novation remotes for that reason) but VST2 simply is an outdated format, specifically on Mac. I really hope that VST3 will find broader support, like AU did.
-
Echoes in the Attic Echoes in the Attic https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=180417
- KVRAF
- Topic Starter
- 12036 posts since 12 May, 2008
Your plug-ins are generally great with automap (except for the tune issue in Diva and a few missing buttons/switches in Zebra). It's entirely the AU format I can't stand.Urs wrote:I'm sorry but I can't help you there. We might be able to workaround Automap (bought a few Novation remotes for that reason) but VST2 simply is an outdated format, specifically on Mac. I really hope that VST3 will find broader support, like AU did.
I guess I'll get JBridge to use u-he stuff in Ableton 64. But I'm not sure yet if JBridge works with automap so we'll see. Otherwise I'll be waiting for VST3 to use -uhe synths in Ableton I guess. Or maybe I'll fancy Bitwig when it comes out.
edit: There seem to be many reports of jbridge working fine with automapped plug-ins.
-
- u-he
- 30194 posts since 8 Aug, 2002 from Berlin
Dunno about bridges, but we always heard of problems with contextual menus not being shown. Those however are pretty vital for our user interface...
-
- KVRAF
- 37409 posts since 14 Sep, 2002 from In teh net
J Bridge is just Windows though - don't know of any decent bridges on Mac.
-
- KVRian
- 932 posts since 26 Nov, 2010
How about jBridgeM?aMUSEd wrote:J Bridge is just Windows though - don't know of any decent bridges on Mac.
-
- KVRist
- 143 posts since 30 Apr, 2010
Meant to ask someone this question for so long, so now seems like the right time to ask you Urs 
- I pretty much use VST all the time for the exact reasons above (on mac). From my perspective, VST always seems a much better format than AU just from usability.
From the users point of view - considering you say 64bit vst2 is outdated on Mac, what exactly are the benefits of AU? Is it just easier from a developers point of view, or are there any quantifiable performance or stability benefits to AU on Mac?
Ive never heard a definitive answer, apart from AU somehow being a more advanced format, and Ive been too polite to ever ask a developer why that is as its the type of question thats quikly passed over alot.
Is it a "much of a muchness" in difference, is there an end user difference or is it just better/easier from the developers end?
Really appreciate if you could throw a little light on it once and for all.
- I pretty much use VST all the time for the exact reasons above (on mac). From my perspective, VST always seems a much better format than AU just from usability.From the users point of view - considering you say 64bit vst2 is outdated on Mac, what exactly are the benefits of AU? Is it just easier from a developers point of view, or are there any quantifiable performance or stability benefits to AU on Mac?
Ive never heard a definitive answer, apart from AU somehow being a more advanced format, and Ive been too polite to ever ask a developer why that is as its the type of question thats quikly passed over alot.
Is it a "much of a muchness" in difference, is there an end user difference or is it just better/easier from the developers end?
Really appreciate if you could throw a little light on it once and for all.
-
- u-he
- 30194 posts since 8 Aug, 2002 from Berlin
Well, in AU we can put multiple plugins into a single component file. I don't see this done very often, but it makes a lot of sense. We can easily share code, resources (images etc.) among multiple instances of different plugins. This is also possible in RTAS, AAX and VST3.
In VST2 this is doable via the shell API. This is however not supported in any host as far as we know, because a certain manufacturer of shell-based VSTs has done it, uhm, in such an exotic way that host manufacturers have only bothered with their way. That's what I heard from several host developers.
So what we do is, we deliver a single VST2 once per bundle and our installer makes exact copies of the binary for each plugin that's normally contained within a shell. This works well, but on Mac we additionally have to patch each single copy to tell it what it actually is (yep, we simply alter the binary after delivery, works like charme)
Now, in future we need to do "code signing" or the stuff won't run on a Mac by default. Thus we can't patch binaries during installation anymore. We'll have to deliver the full throttle 100MB+ downloads with individually signed VSTs.
That's doable, but there's another issue. 64-bit processing on Mac requires the use of Cocoa classes. Those are prone to so called name collisions. In order to avoid name collisions in our framework, we have to do single projects and single compilations for each single VST. And that just totally freaks me out. So, no 64-bit means all Carbon and no such hassle.
Other than that, well, AU has loads of advantages for us. One example: Parameters are not normalised. If we e.g. made a parameter like "Chorus mode" available for automation with, say, 3 states and later on we add a 4th mode, the automation will still be fine in AU, but it'll be f**ked up in VST. This is why we don't make those parameters automatable. I found it a hilarious move to keep parameters normalised in VST3. Facepalm from my side.
Next, VST2 does not have a definition for inputs on instruments, even though nothing speaks against it. We didn't do it in the past because some old hosts can't handle it. AU, RTAS, VST3, AAX, RE have clearly defined input and side chaining behaviour that VST2 completely lacks for instruments. We will disregard this flaw in future and simply add input handling, but we will not advertise this as a feature in VST2 because many hosts don't handle it.
Next. Program Banks. Useless concept for us. Good for small synths, but not for anything in the realm of Zebra.
Ok. VST has a defined MIDI out. CoreMIDI lets you do any number of virtual MIDI outs in an AU that can be routed into any MIDI device on the machine, not just the next plugin. So, hmmm, I don't see why there's a big problem, but then, we haven't done that yet.
Nevertheless, the bundle issue, the code signing issue and the Cocoa name collision hassle are what make me want to drop VST2 support on Mac as soon as possible. It'll take years, but it'll eventually happen. (Note, non of these issues pose a problem on Windows)
In VST2 this is doable via the shell API. This is however not supported in any host as far as we know, because a certain manufacturer of shell-based VSTs has done it, uhm, in such an exotic way that host manufacturers have only bothered with their way. That's what I heard from several host developers.
So what we do is, we deliver a single VST2 once per bundle and our installer makes exact copies of the binary for each plugin that's normally contained within a shell. This works well, but on Mac we additionally have to patch each single copy to tell it what it actually is (yep, we simply alter the binary after delivery, works like charme)
Now, in future we need to do "code signing" or the stuff won't run on a Mac by default. Thus we can't patch binaries during installation anymore. We'll have to deliver the full throttle 100MB+ downloads with individually signed VSTs.
That's doable, but there's another issue. 64-bit processing on Mac requires the use of Cocoa classes. Those are prone to so called name collisions. In order to avoid name collisions in our framework, we have to do single projects and single compilations for each single VST. And that just totally freaks me out. So, no 64-bit means all Carbon and no such hassle.
Other than that, well, AU has loads of advantages for us. One example: Parameters are not normalised. If we e.g. made a parameter like "Chorus mode" available for automation with, say, 3 states and later on we add a 4th mode, the automation will still be fine in AU, but it'll be f**ked up in VST. This is why we don't make those parameters automatable. I found it a hilarious move to keep parameters normalised in VST3. Facepalm from my side.
Next, VST2 does not have a definition for inputs on instruments, even though nothing speaks against it. We didn't do it in the past because some old hosts can't handle it. AU, RTAS, VST3, AAX, RE have clearly defined input and side chaining behaviour that VST2 completely lacks for instruments. We will disregard this flaw in future and simply add input handling, but we will not advertise this as a feature in VST2 because many hosts don't handle it.
Next. Program Banks. Useless concept for us. Good for small synths, but not for anything in the realm of Zebra.
Ok. VST has a defined MIDI out. CoreMIDI lets you do any number of virtual MIDI outs in an AU that can be routed into any MIDI device on the machine, not just the next plugin. So, hmmm, I don't see why there's a big problem, but then, we haven't done that yet.
Nevertheless, the bundle issue, the code signing issue and the Cocoa name collision hassle are what make me want to drop VST2 support on Mac as soon as possible. It'll take years, but it'll eventually happen. (Note, non of these issues pose a problem on Windows)