DP11 is here!

[Michael Canavan]

That is interesting info 60's. Thanks for sharing it!

I am running both Kontakt6 and FM8 under Rosetta2 in MainStage/M1 successfully; I wonder what the difference between the VI coding is?

HCMarkus, you're welcome!

I'll share my non-expert understanding of what's going.
Once difference is that you're running an Intel Mac and I'm using an M1 Mini.
On the M1 Mini, I can also run K6 and FM8 in MainStage.

DP11 in AS (Apple silicon) mode on a M1 Mac
All of my plug-ins as mentioned here earlier are Intel plug-ins running in Rosetta.
This is where things start to get tricky

Only two VST2 plug-ins appear, one which is FM8 which fails. AU is the selected plug-in format, but as mentioned, it's hit or miss. If I try to load certain AU plug-ins, one or two error message appear: DP has encountered an error, and/or always, Emergency Stop which shuts down the audio engine requiring a Quit or Force Quit to restart DP.

DP11 in Rosetta Mode
All AU Intel plug-ins via Rosetta are available.
All VST3 plug-in are now available but Fail. I submitted a TechLink and MOTU says that they're working on VST3 plug-ins passing the scan process.

So for the time being, I save DP in Rosetta mode projects in a Rosetta folder to avoid confusion and the unexpected need to restart DP. I'm quite happy to have K6, Battery, and AD2 running in AS mode.

So if you guys are interested this is my guess as to what's happening here. AU is nearly Apple Silicon ready out the door now, as long as it's a recently updated plug in like Kontakt 6. Most of the pain and suffering of Catalina and Big Sur has been about under the hood changes to make way for the M1 chips.

So this is why NI aren't going to call K6 AS ready right away, they probably haven't tweaked anything to get it ready, it just happened to have most of the tweaks already because of how new the codebase is VS something like Absynth. This is vastly different to what Logic is doing, Logic has code to run non AS approved AU in a AS environment specifically, which apparently isn't that much more efficient according to reports.

I'm pretty happy to hear that the Kontakt 6 AU is working natively already, since when I do jump on the AS bandwagon I would like to avoid using non native plug ins if I can.


VEP is it's own issue, since it's a network plug in, it's running into issue beyond what most plug ins would have. Hopefully VSL get an AS native version of AU, VST and MAS plug in at least out soon enough.

[sockmonkey]

I'm pretty happy to hear that the Kontakt 6 AU is working natively already, since when I do jump on the AS bandwagon I would like to avoid using non native plug ins if I can.

Just to clarify, Kontakt is not working natively, it's still Intel-only. But it runs inside of Rosetta2 within a natively-run (arm64) DP11.

[60s Pop Man]

Just to clarify, Kontakt is not working natively, it's still Intel-only. But it runs inside of Rosetta2 within a natively-run (arm64) DP11.

Yes.
I made a few edits in my previous post to ensure clarity on this point.

[60s Pop Man]

So if you guys are interested this is my guess as to what's happening here. AU is nearly Apple Silicon ready out the door now, as long as it's a recently updated plug in like Kontakt 6. Most of the pain and suffering of Catalina and Big Sur has been about under the hood changes to make way for the M1 chips.

All of this makes sense.
Rosetta takes the immediate pressure off of developers for native AS compatibility. The question is how long before we start to see AS-compatible versions and a noticeable performance boost.

In the short term, hopefully MOTU will make improved scanning of Intel VST3 plugins a priority. DP11's Articulation Map function will automatically generate the maps for VST3 instruments coded to do so. True of VST 2 versions as well if coded to do so but I don't have any that work on my system at the moment. S1 5.3 already can do this effortlessly.

[Michael Canavan]

Just to clarify, Kontakt is not working natively, it's still Intel-only. But it runs inside of Rosetta2 within a natively-run (arm64) DP11.

Yes.
I made a few edits in my previous post to ensure clarity on this point.

So there has been zero indication of DP arm native being able to run plug ins in Rosetta mode. The more likely scenario again like I mentioned is that AU is already specked close enough to M1 native for the OS to read it as native, if the plug in is following all of Apple’s rules for Big Sur etc.

There’s only one DAW I know of that runs both native and Rosetta plug ins side by side and that’s Bitwig, due to its ability to sandbox a plug away from the host, and 100% DP does not do that.

[sockmonkey]

Just to clarify, Kontakt is not working natively, it's still Intel-only. But it runs inside of Rosetta2 within a natively-run (arm64) DP11.

Yes.
I made a few edits in my previous post to ensure clarity on this point.

So there has been zero indication of DP arm native being able to run plug ins in Rosetta mode. The more likely scenario again like I mentioned is that AU is already specked close enough to M1 native for the OS to read it as native, if the plug in is following all of Apple’s rules for Big Sur etc.

There’s only one DAW I know of that runs both native and Rosetta plug ins side by side and that’s Bitwig, due to its ability to sandbox a plug away from the host, and 100% DP does not do that.

Wait, what? That's exactly what I said: Kontakt (Intel-only) runs as an AU plugin via Rosetta2 inside of a DP11 running natively on an M1 system.

That is: the host is arm64 (AS), the plugin is x86_64 (Intel), and they work together. The "spec" of the plugin is irrelevant: a plugin is a binary library which needs to be read by the host, and it either has an arm64 binary component or not. Kontakt does not, AND it runs in arm64-native Digital Performer.

So that is a positive indication of DP arm native being able to run plugins in Rosetta mode.

EDIT: if you open Activity Monitor, you can see two lines:

Code: Select all

Digital Performer	Apple	
AUHostingCompatibilityService (Digital Performer)	Intel

This AUHostingCompatibilityService is the (transparent) mechanism for leveraging Rosetta2 on arm64 systems to run Intel plug-in binaries. I suspect there's no similar support for VST/VST3, though.

[Michael Canavan]

Yes.
I made a few edits in my previous post to ensure clarity on this point.

So there has been zero indication of DP arm native being able to run plug ins in Rosetta mode. The more likely scenario again like I mentioned is that AU is already specked close enough to M1 native for the OS to read it as native, if the plug in is following all of Apple’s rules for Big Sur etc.

There’s only one DAW I know of that runs both native and Rosetta plug ins side by side and that’s Bitwig, due to its ability to sandbox a plug away from the host, and 100% DP does not do that.

Wait, what? That's exactly what I said: Kontakt (Intel-only) runs as an AU plugin via Rosetta2 inside of a DP11 running natively on an M1 system.

That is: the host is arm64 (AS), the plugin is x86_64 (Intel), and they work together. The "spec" of the plugin is irrelevant: a plugin is a binary library which needs to be read by the host, and it either has an arm64 binary component or not. Kontakt does not, AND it runs in arm64-native Digital Performer.

So that is a positive indication of DP arm native being able to run plugins in Rosetta mode.

EDIT: if you open Activity Monitor, you can see two lines:

Code: Select all

Digital Performer	Apple	
AUHostingCompatibilityService (Digital Performer)	Intel

This AUHostingCompatibilityService is the (transparent) mechanism for leveraging Rosetta2 on arm64 systems to run Intel plug-in binaries. I suspect there's no similar support for VST/VST3, though.

That’s interesting to say the least! So DP only able to host around three AUs right? It looks like it’s able to inadvertently tag into Apples built in code for Logic etc. That’s cool but it 100% explains the high failure rate. In other words MOTU haven’t coded anything besides proper native AS code, its more like a side affect that it can. Again the fact that Kontakt 6 is able to run is probably mostly due to its newer codebase and it’s no surprise old FM8 can’t run.

So compare this to Bitwig, they do a sandboxing routine on plug ins and only run VSTs. The claim is to be able to run both native plug ins and Rosetta plug ins at the same time, in VST, VST3 format. I’m using this as an example because it’s obvious to me anyway this is an unsupported side affect that you can run intel plug ins in a native version of DP11. They certainly don’t mention it anyway.

[toodamnhip]

DP11, costing $195 to "upgrade", runs poorly in self-forced Rosetta mode

It's not DP 11 that runs in Rosetta mode. It's the 3rd party plugins that haven't been updated.

My point was that DP10.3 runs better in Rosetta mode than DP11, at least for the VSL plug-ins. So in this particular use case, the paid upgrade is not worth it.

That said, DP10, for me, runs wonderfully in Rosetta. I'm not really losing out on much other than Articulation Maps and MPE, which I would love to have.

Also, to address the other issue someone raised, due to the memory efficiency of AS, I am not finding 16GB limiting in running my orchestral templates. Having the sample libraries running off a NVME makes all the difference in the world. I would advise keeping the RAM tidy with Memory Clean 3, as well.

Can you share real benefits you have observed from running memory clean? The site reminds me of some of them gimmicky Mac cleaning apps made for laymen that screw up ones computer of not run carefully.

[gulliverity]

Per toodamnhip's question...

Not to stray from the topic of this thread, but this is a continuation of discussion of how DP11 (and DP10) performs on the M1 ecosystem with seemingly too little RAM. My experience was DP10.13 is solid and DP11 is up for debate. VSL plug-ins are hopeless in it (processor maxing out), but I am reading here that M1 users with Kontakt are getting solid performance so everyone's mileage will vary. I am presuming all of them have the maximum 16GB as I do. Apples/apples.

Memory Clean 3 is no gimmick and, fortunately, you can try it for free. The real advantage, though, is paying the ten bucks so you can run the Extreme Clean routine. It routinely gives me back 2-4GB of RAM after I close a RAM-hungry application such as Safari or Chrome.

On my Macbook Pro M1, any time my playback of orchestral virtual instruments gets a bit stuttery, I discover I had left the web browser still running. Quitting the application is "supposed" to make that RAM available again, but Apple does a lousy job of it. MC3 has an option to automatically reclaim memory upon an application's quit. Handy as heck. Anyway, 100% of the time MC3 has done the trick for me; whatever playback issue I was having for an audio or video app disappears...presuming it was playing back smoothly previously. (My media is on NVMEs so it's never about the disk speed.)

[sockmonkey]

So compare this to Bitwig, they do a sandboxing routine on plug ins and only run VSTs. The claim is to be able to run both native plug ins and Rosetta plug ins at the same time, in VST, VST3 format. I’m using this as an example because it’s obvious to me anyway this is an unsupported side affect that you can run intel plug ins in a native version of DP11. They certainly don’t mention it anyway.

That sounds about right. I don't know the details of the Bitwig implementation, but it sounds like they spawn a helper process with the appropriate architecture for every plugin instance and pass audio, MIDI and parameter data back and forth via inter-process mechanisms/shared memory/whoknowswhat. If it's performant, that is a great solution for crashy plugins with the (probably unintended, but useful) side effect of running multiple architectures on macOS.

[waterstrum]

Re: Memory cleaning....

Obviously a reboot is the best way.

I often end up with multiple open apps and shrinking available ram.
Sometimes I don't want to reboot.

I've been using CleanMyMac and it has a nice assortment of tools.
Usually gets me back to a reasonable number... just now from 4GB to 29GB of available ram.
Just installed MC3 and it goes a bit beyond.
Just did the extreme clean and went from 29GB to 41GB. CMM reports 39GB.

Nice tools if you need them.

[Michael Canavan]

So compare this to Bitwig, they do a sandboxing routine on plug ins and only run VSTs. The claim is to be able to run both native plug ins and Rosetta plug ins at the same time, in VST, VST3 format. I’m using this as an example because it’s obvious to me anyway this is an unsupported side affect that you can run intel plug ins in a native version of DP11. They certainly don’t mention it anyway.

That sounds about right. I don't know the details of the Bitwig implementation, but it sounds like they spawn a helper process with the appropriate architecture for every plugin instance and pass audio, MIDI and parameter data back and forth via inter-process mechanisms/shared memory/whoknowswhat. If it's performant, that is a great solution for crashy plugins with the (probably unintended, but useful) side effect of running multiple architectures on macOS.

That sounds about right, the program lets you choose whether to run plug ins in host, individually or by manufacture with the ability to override your setting for individual plug ins. It does cost some CPU and probably memory to do this, but it's not much in my experience. I would love it if MOTU kipped this for DP, instead it seems MOTU rely heavily on the initial validation process, which is iffy at best. A crashing plug in doesn't crash Bitwig, the plug in istself crashes, and the side affect of having that architecture in place seems to be that they could run Rosetta plug ins alongside native plug ins. I don't have an AS mac yet so I can't test it, so this is all theoretical really, but I'm not reading a rash of people complaining it doesn't work so there's that.

[sockmonkey]

That sounds about right,...

Bitwig seems to do a bunch of things "right", although I don't know how well-suited it is for "linear" composition workflows, I've just never tried. Unfortunately, it doesn't support sysex and is therefore a non-starter as far as I am concerned. Maybe some future version will.

[Michael Canavan]

That sounds about right,...

Bitwig seems to do a bunch of things "right", although I don't know how well-suited it is for "linear" composition workflows, I've just never tried. Unfortunately, it doesn't support sysex and is therefore a non-starter as far as I am concerned. Maybe some future version will.

You named my major shortcoming with it, SysEx support. Plus I don't think it's that suited to large templates, it works very well for small projects, there's a lot of things it does there I wish Bitwig did, but to it's credit you can select and unfold a group/folder track, which is something I wish DP could do. It's a bit of a CPU pig so large projects would end up difficult to manage.

[60s Pop Man]

So DP11 running in native AS mode loads the latest specked close enough for M1 AU version of Falcon, HALion Sonic, and Cubase plug-ins Padshop and Retrologue. Old-code Absynth like FM8 does not load.