4 ms·

Yeah, I'm completely satisfied. The M1 Pro is definitely the best computer for the money I've purchased, despite it costing an arm and a leg to get more RAM and

Yeah, I'm completely satisfied. The M1 Pro is definitely the best computer for the money I've purchased, despite it costing an arm and a leg to get more RAM and SSD space. For my workload (music production), and despite still having to run Ableton through Rosetta, it can handle roughly twice as many tracks as my 2018 MBP (which luckily is _not_ something I purchased). All my previous "problem" projects now run perfectly. And this is all while running completely silently and barely getting warm compared to my 2018 MBP, which runs fans full blast and gets super hot if I so much as glance at Ableton. Can't say I miss the hiss of the fan when I'm trying to mix tracks. If the developers of plugins I use all the time ever get their ducks in a row and finally get around to updating them to support native ARM (that's the current limiting factor), I imagine it will be even better. Kind of embarrassing that it's taking some devs so long.. Steve Duda managed to get Serum updated within a couple months of the original M1 release.

readyp1 5y ago
I'm currently testing an M1-based Air to see if I'd like to purchase something similar. I can confirm this for sure; the project files that made my current, not-even-old Windows laptop with similar stats choke are running like a dream even on this Air. BTW, if you have a license for Live 11, version 11.1 forward has a Universal build, so it can run natively on M1 Macs rather than through Rosetta. [0] [0] https://help.ableton.com/hc/en-us/articles/115001261150-Mac-Compatibility-with-Live https://help.ableton.com/hc/en-us/articles/115001261150-Mac-...
- tallytarik 5y ago
  The parent commenter's problem sounds like it's third-party plugins rather than Live itself. FL Studio also has a build for ARM, but it runs each non-ARM plugin in a wrapper which somehow uses an entire CPU core. After loading more than a couple of plugins I see something that is otherwise unheard of on my M1 Macbook - 1000% CPU usage and fans at full speed. So I stick to running the app via Rosetta - higher-than-average CPU usage in general, but it means my plugins behave.
- ungamedplayer 5y ago
  Also, you can't compare io work on OSX to anything else, it's fsync () is a no-op. When file cache can stream to disk at a delay, io always looks super fast. I guess the risk of data loss is acceptable .
smoldesu 5y ago
> Kind of embarrassing that it's taking some devs so long.. Steve Duda managed to get Serum updated within a couple months of the original M1 release. Is it? Steve Duda has no choice, his lunch is getten eaten by Matt Tytel and the folks at Native Instruments. If he wants to keep selling his $150+ plugin, he better stay on the cutting edge. For everyone else though, I find it hard to blame them. Overnight you get a complete architecture change that you need to buy test hardware for, test-compile for ARM, find out what breaks, source new ARM-compatible libraries for what dod break, re-write some/all of your codebase to account for these changes, profile the performance difference, re-evaluate if the native version is worth it, then set up a testing and CI pipeline for a second architecture. Since most of these plugins are written with the notoriously fragile JUCE framework in C++, I can see why it's not just an overnight task to get it working on Apple Silicon unless you drop everything and make it your top priority.
- thatswrong0 5y ago
  Duda.. getting his lunch eaten by Native Instruments? Vital I understand (a sort-of-free Serum-like synth is certainly a competitor).. but Native Instruments hasn't done anything interesting in the VST space in years. Odd to throw that in there. My point is that companies like Native Instruments have vastly more resources and developers than one individual developer, and still very few of their supposedly flagship products are M1 compatible. It's been a year and a half, and Massive X still isn't updated. You'd think they would toss at least one developer at it. I guess that maybe points to organizational rot more than anything (I guess Massive X generally being an outdated flop is also evidence of this), but the point stands.
- Joeri 5y ago
  For everyone else though, I find it hard to blame them. Overnight you get a complete architecture change Except it didn’t happen overnight, Apple announced it 6 months in advance. There has been affordable hardware available for porting since june 2020, almost 2 years ago. If a developer hasn’t gotten around to it by now, I doubt it is a priority for them, let alone their top priority.
  - 5y ago
teilo 5y ago
> Kind of embarrassing that it's taking some devs so long.. Steve Duda managed to get Serum updated within a couple months of the original M1 release. This is seriously overstating things. Steve has spent years continuously optimizing his code base. It was already clean and relatively free of cruft compared to code bases of similar age. If you are developing on something like JUCE and don't have an extensive amount of optimized assembly or AVX instructions to deal with, yeah, porting is fast. Likewise if your suite uses a common framework (ala MeldaProduction, FabFilter, uHe, etc.). NI's code base is not clean, and they have the organizational problem of developers coming, developing a product, and then leaving, orphaning the code base. Brian Clevinger is doing his own thing now with Rhizomatic, so good luck every seeing Absynth native. But NI has maintained active development of Kontakt because it is their cash cow, and thus their first native release. But Reaktor? Massive? Massive X? Nowhere in sight. Further, like many developers, they have the added problem of VST3, which is a royal PITA to get right. Since Steinberg is trying to pull the rug out from all native VST2 development on M1, many larger developers like NI don't want to risk the potential lawsuits. They also have no choice but to push out native VST3s, since Cubase 12 does not support native VST2s. So there are a lot of economic and technical pressures at work that you have to take into account.
- thatswrong0 5y ago
  I think I definitely misspoke here - I really didn't mean the devs so much as the companies that employ them. I know full well how difficult such a transition could be. Native Instruments has a ton of resources, and you'd think at the very least their most recent "flagship" synth Massive X would have seen an update by now.. which definitely points to organizational cruft more than anything. Most of the plugins I use that are created by smaller teams have already been updated. The fact remains though that a loooot of producers use Macbook Pros, and I'm assuming many will be upgrading to M1s within the next couple years. I'm genuinely curious when the pressures will actually force these large organizations to take the transition seriously.
  - teilo 5y ago
    This is why I am very hopeful for the future of CLAP. It will give all developers a common format to target and test that can be wrapped in VST2/3/AU/AAX relatively easy. Since it has an ABI vs. and API interface, it is not subject to the vagaries of any one company's proprietary idea of how plugins will work. This will also make porting to new architectures easier. VST2 used to be the standard development and testing target, which was then wrapped to other formats. But all of the developer workflows built around it are now at risk because of Steinberg's asshattery. I know for a fact that this has delayed a number of plugin releases, as developers have to put time into refactoring their code around a new standard target. Thank God for u-He and Bitwig leading the way here. I've tested the Surge XT CLAP build in Bitwig and it just works.

readyp1 5y ago

I'm currently testing an M1-based Air to see if I'd like to purchase something similar. I can confirm this for sure; the project files that made my current, not-even-old Windows laptop with similar stats choke are running like a dream even on this Air. BTW, if you have a license for Live 11, version 11.1 forward has a Universal build, so it can run natively on M1 Macs rather than through Rosetta. [0] [0] https://help.ableton.com/hc/en-us/articles/115001261150-Mac-Compatibility-with-Live https://help.ableton.com/hc/en-us/articles/115001261150-Mac-...

tallytarik 5y ago
The parent commenter's problem sounds like it's third-party plugins rather than Live itself. FL Studio also has a build for ARM, but it runs each non-ARM plugin in a wrapper which somehow uses an entire CPU core. After loading more than a couple of plugins I see something that is otherwise unheard of on my M1 Macbook - 1000% CPU usage and fans at full speed. So I stick to running the app via Rosetta - higher-than-average CPU usage in general, but it means my plugins behave.
ungamedplayer 5y ago
Also, you can't compare io work on OSX to anything else, it's fsync () is a no-op. When file cache can stream to disk at a delay, io always looks super fast. I guess the risk of data loss is acceptable .

smoldesu 5y ago

> Kind of embarrassing that it's taking some devs so long.. Steve Duda managed to get Serum updated within a couple months of the original M1 release. Is it? Steve Duda has no choice, his lunch is getten eaten by Matt Tytel and the folks at Native Instruments. If he wants to keep selling his $150+ plugin, he better stay on the cutting edge. For everyone else though, I find it hard to blame them. Overnight you get a complete architecture change that you need to buy test hardware for, test-compile for ARM, find out what breaks, source new ARM-compatible libraries for what dod break, re-write some/all of your codebase to account for these changes, profile the performance difference, re-evaluate if the native version is worth it, then set up a testing and CI pipeline for a second architecture. Since most of these plugins are written with the notoriously fragile JUCE framework in C++, I can see why it's not just an overnight task to get it working on Apple Silicon unless you drop everything and make it your top priority.

thatswrong0 5y ago
Duda.. getting his lunch eaten by Native Instruments? Vital I understand (a sort-of-free Serum-like synth is certainly a competitor).. but Native Instruments hasn't done anything interesting in the VST space in years. Odd to throw that in there. My point is that companies like Native Instruments have vastly more resources and developers than one individual developer, and still very few of their supposedly flagship products are M1 compatible. It's been a year and a half, and Massive X still isn't updated. You'd think they would toss at least one developer at it. I guess that maybe points to organizational rot more than anything (I guess Massive X generally being an outdated flop is also evidence of this), but the point stands.
Joeri 5y ago
For everyone else though, I find it hard to blame them. Overnight you get a complete architecture change Except it didn’t happen overnight, Apple announced it 6 months in advance. There has been affordable hardware available for porting since june 2020, almost 2 years ago. If a developer hasn’t gotten around to it by now, I doubt it is a priority for them, let alone their top priority.
- 5y ago

teilo 5y ago

> Kind of embarrassing that it's taking some devs so long.. Steve Duda managed to get Serum updated within a couple months of the original M1 release. This is seriously overstating things. Steve has spent years continuously optimizing his code base. It was already clean and relatively free of cruft compared to code bases of similar age. If you are developing on something like JUCE and don't have an extensive amount of optimized assembly or AVX instructions to deal with, yeah, porting is fast. Likewise if your suite uses a common framework (ala MeldaProduction, FabFilter, uHe, etc.). NI's code base is not clean, and they have the organizational problem of developers coming, developing a product, and then leaving, orphaning the code base. Brian Clevinger is doing his own thing now with Rhizomatic, so good luck every seeing Absynth native. But NI has maintained active development of Kontakt because it is their cash cow, and thus their first native release. But Reaktor? Massive? Massive X? Nowhere in sight. Further, like many developers, they have the added problem of VST3, which is a royal PITA to get right. Since Steinberg is trying to pull the rug out from all native VST2 development on M1, many larger developers like NI don't want to risk the potential lawsuits. They also have no choice but to push out native VST3s, since Cubase 12 does not support native VST2s. So there are a lot of economic and technical pressures at work that you have to take into account.

thatswrong0 5y ago
I think I definitely misspoke here - I really didn't mean the devs so much as the companies that employ them. I know full well how difficult such a transition could be. Native Instruments has a ton of resources, and you'd think at the very least their most recent "flagship" synth Massive X would have seen an update by now.. which definitely points to organizational cruft more than anything. Most of the plugins I use that are created by smaller teams have already been updated. The fact remains though that a loooot of producers use Macbook Pros, and I'm assuming many will be upgrading to M1s within the next couple years. I'm genuinely curious when the pressures will actually force these large organizations to take the transition seriously.
- teilo 5y ago
  This is why I am very hopeful for the future of CLAP. It will give all developers a common format to target and test that can be wrapped in VST2/3/AU/AAX relatively easy. Since it has an ABI vs. and API interface, it is not subject to the vagaries of any one company's proprietary idea of how plugins will work. This will also make porting to new architectures easier. VST2 used to be the standard development and testing target, which was then wrapped to other formats. But all of the developer workflows built around it are now at risk because of Steinberg's asshattery. I know for a fact that this has delayed a number of plugin releases, as developers have to put time into refactoring their code around a new standard target. Thank God for u-He and Bitwig leading the way here. I've tested the Surge XT CLAP build in Bitwig and it just works.