Tracking Apple Silicon Native Hosts, Plugins, Effects

[Ploki]

I went for Max because memory speed is faster than in Pro.
Max = 400GB/s memory bandwidth,
Pro = 200GB/s memory bandwidth

Hmm might be some plug-in affecting the freeze when changing buffers

That’s what I thought about as well, but i’d like to see some benchmarks.
Original M1 has ~70GB/s.
I might wait for M2 tho, not yet set. If i go for Max its gonna be for a longer time.

Some plugins are picky when reloading and might take a while - some might freeze logic up, i’ve experienced it already but on older versions and intel.

[teilo]

The doubled memory bandwidth on the Max will not come into play in music production. So far, testing reveals that it is very difficult to saturate the memory bus beyond the capacity of the Pro, since the SSD and CPU will top out well before the memory bus.

I also went with the M1 Max, but that's for the 64Gb of RAM, and the doubled GPU power. I use some very large Hauptwerk organs and can use the RAM. I also do software development and rely upon VMs, which eat RAM.

[Ploki]

I suspected that the difference in memory bus performance for audio is probably not nearly as dramatic as the price hike.
I mean - because even the original M1’s 72gb/s is pretty fast.

Thanks for the insight

[Tronam]

The higher memory bandwidth also helps facilitate the increased number of supported external displays.

[Ploki]

The higher memory bandwidth also helps facilitate the increased number of supported external displays.

I don’t think you’re making the correct causation there - that’s because it simply has another (similar) additional GPU unit.
Memory bandwidth doesn’t appear to bear significance for CPU work.
https://www.anandtech.com/show/17024/ap ... e-review/2

[tajika]

PSP MasterQ2 is apple silicon native as of version 2.1.1

https://www.pspaudioware.com/products/psp-masterq2

[kidslow]

Preparing to install a couple of DAWS (Reaper & Studio One) and a lot of plugins on an M1 mac. Can anyone share how they are managing native ARM silicon vs Rosetta universal binaries side-by-side. Seems like it could get messy.

In exchange for a remarkably more efficient CPU, seems worth it to be deliberate about this. My belief, and it stands to reason, is that a native DAW compiled for ARM with native ARM plugins will see the best processor performance. I read that running any one plugin in Rosetta mode during a session will mean that all plugins in that session will run performance degraded, at least as compared to running all native. It makes sense. Can anyone confirm all this?

What I am thinking is to use /Library/Audio/Plug-ins for the native silicon plugs and ~/Library/Audio/Plug-ins for the Rosetta versions [~ being Unix notation for home directory]. Some vendors don't like if you move their plugins from /Library to ~/Library ... but if I go slow should be reasonably able to segregate on disk. Those are the two standard locations for those. Maybe I should even put them in a non-standard directory structure, so there's no way they'd get scanned without prompting. I've done that with Acustica in the past because their plugins are an ugly mess of files.

My goal is to be flexible enough to use Rosetta mode for plugins that are not yet native, but keep them segregated, so when I open one I do so deliberately with knowledge that it's going to throttle my performance. Then I could add/remove plug-in folders reported to the DAW and rescan to manage things. A bit of a chore, but best solution I've been able to imagine.

I definitely now have a sense of which developers are on top of their work, and which are bogged down in legacy code, and who is just completely hopelessly lost. Seems like, "We've tested in Rosetta," is unfortunately a standard response. By now I would hope that all active developers, if not refactored to ARM native, are at least talking publicly about their plans. If they're still silent a year on, my trust level in their ability to tend to their software in the future is eroded and maybe their plugins cannot be relied on going forward.

[Ploki]

I didnt experience “general slow down” when opening one rosetta plugin in logic. They use a separate process (visible in activity monitor) so they are unrelated. At least in logic - but for AU i think all daws use macOS hosting process.

I keep them in the same folder and just tend to use native plugins more. I learned some things while shedding some unnecessary weight it was a good process

[Double Tap]

Preparing to install a couple of DAWS (Reaper & Studio One) and a lot of plugins on an M1 mac. Can anyone share how they are managing native ARM silicon vs Rosetta universal binaries side-by-side. Seems like it could get messy.

In exchange for a remarkably more efficient CPU, seems worth it to be deliberate about this. My belief, and it stands to reason, is that a native DAW compiled for ARM with native ARM plugins will see the best processor performance. I read that running any one plugin in Rosetta mode during a session will mean that all plugins in that session will run performance degraded, at least as compared to running all native. It makes sense. Can anyone confirm all this?

What I am thinking is to use /Library/Audio/Plug-ins for the native silicon plugs and ~/Library/Audio/Plug-ins for the Rosetta versions [~ being Unix notation for home directory]. Some vendors don't like if you move their plugins from /Library to ~/Library ... but if I go slow should be reasonably able to segregate on disk. Those are the two standard locations for those. Maybe I should even put them in a non-standard directory structure, so there's no way they'd get scanned without prompting. I've done that with Acustica in the past because their plugins are an ugly mess of files.

My goal is to be flexible enough to use Rosetta mode for plugins that are not yet native, but keep them segregated, so when I open one I do so deliberately with knowledge that it's going to throttle my performance. Then I could add/remove plug-in folders reported to the DAW and rescan to manage things. A bit of a chore, but best solution I've been able to imagine.

I definitely now have a sense of which developers are on top of their work, and which are bogged down in legacy code, and who is just completely hopelessly lost. Seems like, "We've tested in Rosetta," is unfortunately a standard response. By now I would hope that all active developers, if not refactored to ARM native, are at least talking publicly about their plans. If they're still silent a year on, my trust level in their ability to tend to their software in the future is eroded and maybe their plugins cannot be relied on going forward.

Don't sweat it too much - it really doesn't make a lot of difference. I keep forgetting which ones are translated. In the tests I've done I've had good performance whether I'm running only native or with translated plugins.

Monterey noticeably speeded things up for me - quicker boot times for everything.

Edit: You really shouldn't see anything like "throttling". When I have performance issues it's usually quite specific patches, including with plugins in a native build.

[kidslow]

Don't sweat it too much - it really doesn't make a lot of difference. I keep forgetting which ones are translated. In the tests I've done I've had good performance whether I'm running only native or with translated plugins.

Monterey noticeably speeded things up for me - quicker boot times for everything.

Edit: You really shouldn't see anything like "throttling". When I have performance issues it's usually quite specific patches, including with plugins in a native build.

Thanks for the report. Interesting about Monterey. That was not on my list of upgrades, but perhaps should consider it.

It was the performance comparison in this article that suggested to me that there is enough difference to justify the extra work of trying to stick to native ARM. https://www.pro-tools-expert.com/produc ... ve-results

[Ploki]

Yes try stick to native in general but rosetta plugins wont make native plugs slower

[kidslow]

Yes try stick to native in general but rosetta plugins wont make native plugs slower

Thanks for the confirmation Ploki. I'll probably install my plugins segregated, because well why not, but good to hear that Rosetta won't slow other native plugins down when running alongside.

[Double Tap]

Don't sweat it too much - it really doesn't make a lot of difference. I keep forgetting which ones are translated. In the tests I've done I've had good performance whether I'm running only native or with translated plugins.

Monterey noticeably speeded things up for me - quicker boot times for everything.

Edit: You really shouldn't see anything like "throttling". When I have performance issues it's usually quite specific patches, including with plugins in a native build.

Thanks for the report. Interesting about Monterey. That was not on my list of upgrades, but perhaps should consider it.

It was the performance comparison in this article that suggested to me that there is enough difference to justify the extra work of trying to stick to native ARM. https://www.pro-tools-expert.com/produc ... ve-results

Yeah, I should caveat that and say I don't use Studio One, and I don't think Ableton (which I do use) have really cracked the native build yet - Live is still in beta to be fair.

[Ploki]

Studio one works pretty hood, but it’s not my main so I don’t use it nearly as much as logic

[sveinbjorn]

I didnt experience “general slow down” when opening one rosetta plugin in logic. They use a separate process (visible in activity monitor) so they are unrelated. At least in logic - but for AU i think all daws use macOS hosting process.

This may be, but they’re as goofy as hell in ableton. Its clear that they’re running through a layer, general sloth plus a glitchier, slower interface.

I’m verging on giving up on the native version of ableton. For now at least.