New M1 Mac Mini Runs 444 Voices, 555 Plugin Instances

The latest Sonic State Sonic Lab video takes a quick look at the new Mac Mini, one of Apple’s new entry-level MacOS computers.

The introductions have upturned expectations for MacOS computers, because the M1 system-on-a-chip is optimized in ways that desktop users are not used to, and the company’s bottom-of-the-line Macs based on the new M1 perform at a level that beats or at least competes with last year’s top-of-the-line maxed out systems.

In the video, host Nick Batt takes a look at the cheapest of the M1 Macs, a Mac Mini with an 8-core CPU, 8GB of RAM and 256GB hard drive. He tried a variety of tests, creating 111 tracks with 444 voices and 555 plug-in instances (native) before the machine slowed to a crawl.

“This little computer packs a lot of punch for the price,” he notes. “But at present only really in true native mode can you expect this kind of performance.”

This is bleeding edge for musicians. Most will not want to switch to an M1 Mac until developers and software have a chance to catch up to the new systems. But ‘Apple Silicon’ is starting to look like one of those ‘game changers’ that actually lives up to the term.

Check out the video and share your thoughts on the new M1 Macs in the comments!

63 thoughts on “New M1 Mac Mini Runs 444 Voices, 555 Plugin Instances”

    1. With you on the second part. It feels almost unhealthy how much of a difference in my life this MBAM1 makes.

      Wouldn’t be that quick on the first part. In #MusicTech especially, Intel Macs are likely to remain relevant for a while. Performance can be extremely important in some situations… and we’ll have to assess how robust and reliable that performance can be in stressful situations. I love my MBAM1… and have been experiencing hard crashes, even to the extent that it rebooted itself unattended.
      There’s also the stuff about RAM and ports. Sure, RAM needs are surprising a lot of people as being lower than on Intel chips in equivalent use cases. But there are cases where loading huge libraries in RAM might be essential. Two Thunderbolt ports is fine for some needs but we can easily imagine scenarios where a lot more would be needed.
      So, it’s quite possible that Apple will release in 2021 those amazing machines with M2 chips which can have a whole lot more RAM and a lot of ports. We’re not there, yet.

      1. Exactly. If you own hundreds of plugins like i do, while m1 might seem cool,,, NO WAY i am transitioning in less than a year. 1 ) NO WAY i am changing OS 2) No way i risk working on Rosetta in advanced CPU intensive projects inAbleton. While it works nice with Logic, Ableton in rosetta is not that smooth CPU wise. A 2014 i7 15″ macbook can handle more instances in Ableton than the Macbook pro m1…… So even when Ableton becomes native on m1 best case scenario it will be 5% better than a 16″ i9. No sir. I will wait a year. But to everyone who got it and like it i wish you a good time with it! If i had Logic i would have bought it like… yesterday

  2. Universal Audio hasn’t announced hardware support for the M1, and I haven’t seen official announcements from Native Instruments, Ableton, Arturia and others. I suspect things will be a lot more solid in about 6 months. It’s not like I’m leaving the house, anyway…

  4. “until developers and software have a chance to catch up”.
    In fact, they’ve been able to do that since June, when the macOS 11 beta and Apple Silicon dev kits became available (you don’t strictly need a dev kit or new Mac to work on your changes. Only to test them)

    It’s the same thing every year, but most audio software companies still play dead until October when they mass e-mail “OMG don’t upgrade, we never knew this would happen, we’re gonna take a look now ! Maybe. Give us a few months”

    A lot of other software on my Mac gets updates for the new OS over the summer. Do audio companies know they can get away with it because musicians are super conservative with upgrades ?

    1. The M1-equipped Macs only started reaching customers on November 17, meaning that the major companies have only had two weeks with real M1-equipped hardware at this point. The production release of Big Sur is only a few weeks old as well.

      Your comment demonstrates that you don’t have experience migrating a large and potentially mature codebase to a new platform while *also* worrying about the development of new software for other platforms, all during a pandemic that keeps teams apart.

      1. I actually have 20 years experience in software dev but that’s not even needed to fact-check your reply.

        There is exactly one feature that production M1 Macs have that the dev kit CPU didn’t : hardware virtualisation support. Period. So unless you’re VMWare or Docker, sorry, you don’t get to use that excuse.

        You could have had your ARM dev kit since June and have solved 100% of architecture-related issues with it *just as well* as you can do with a production M1 today. Except you would have started 5 months ago. And you shouldn’t have that many arch-related issues anyway, unless you have handcrafted assembly, do weird things with memory or use tons of binary-only frameworks. I don’t think that’s the case for most of those who are complaining, let’s be honest !

        Didn’t have the money for a dev kit ? Not as easy but you could still have done the bulk of the work and cross-compiled for ARM until your build passed, and by now you would have had a good chance that it just worked.

        When you say “large mature codebase”, do you mean “I’m using frameworks that have been deprecated for 10 versions and have tech debt as high as the Everest that I never get around to fixing”.
        Sorry again, that’s cool if you’re a one man shop but if you’re a team with an engineering manager it’s just part of their job to not wait until the s**t hits the fan.

        I have zero sympathy for the guys who got caught out with their 32-bit only software on Catalina and pointed fingers at Apple who gave them TWO years notice to do a 64-bit migration that was a thing on macOS for ELEVEN years !

        Planning-wise. Apple OS betas start in June at WWDC and the new OS gets released in the autumn like clockwork, for what, 10-15 years ? If you really can’t plan your workload around that and it always comes as a disruptive surprise, maybe you shouldn’t be in the business of making commercial Mac software.

        2. Thank you for this much-deserved rant.

          I agree, one-person boutique VST makers should get some slack on this, but if you’re Steinberg or NI, there’s absolutely no excuse for waiting to *start* work on compatibility until the retail release of a new MacOS. This would be unacceptable in certain other industries where professionals might have a sudden need to replace a computer, and the new ones available at retail aren’t compatible because the software vendor ignored Apple’s beta period, yet somehow it’s the norm in pro audio.

          I won’t even let Apple off the hook entirely here, as they tend to be overly hard-nosed in deprecating frameworks and pushing software vendors toward new solutions with every OS version. But they’ve also been consistent in this for years, and makers of professional software should know by now what to expect.

          1. You’ve got it backwards.

            Companies like Sinevibes or ValhallaDSP, which are essentially one genius developer, will have their stuff moved over the quickest.

            What previous commenters don’t take into account is that modern DAWs are massively complex code bases, plus they have licensed code dependencies, plus there’s the reasonable expectation that your DAW will be relatively bulletproof.

            Just about nobody but Apple can make that sort of overhaul quick enough to release it when new hardware comes out, and it’s also reasonable to expect that developers should actually test a DAW on production hardware.

            1. We’re mostly talking about plugins not DAWs.

              Even then, the debate is about when they should *start* the work, not complete it. In many cases there isn’t even actual coding work to do some years, besides testing.

              And it’s not just about this new hardware transition (which will be barely more difficult than any other year anyway, if you follow good practices and don’t use deprecated APIs).
              Audio software devs pull the same excuses every year.

        3. I’ll share some recent real-world experience with Apple. I’m a hardware guy who spent several months this year fighting with issues enumerating iPad Pros with our gear. Everything else worked fine except the small stack of iPads in our office. Our hardware and software teams worked with the chipset manufacturer to resolve the issue until one day the iPad behavior spontaneously fixed itself following an iPadOS update. Apple has a nasty habit of hiding incomplete or broken functionality and quietly fixing it at some point in the future.

          When it came to Big Sur and the Apple Silicon rollout, our team couldn’t qualify our gear until we had production hardware and software in hand. A dev kit running on an iPad processor isn’t good enough to confirm that Thunderbolt will work as expected on M1 machines. A dev kit running a beta of Big Sur doesn’t reflect the exact functionality of the release version. And qualification isn’t a simple 10 minute process. It takes days to systematically check various devices against multiple Apple machines. To make things even more unpredictable, Apple is virtually guaranteed to force you to restart the process by updating macOS within the first week or two.

          While all this is going on, anonymous commenters are calling us out for being slow and incompetent on industry blogs like this one.

          1. I think we misunderstood each other, your stance sounds much more reasonable now.

            You’re dealing with hardware: of course chipset-level bugs or implementation differences matter much more to what you’re doing, and they’re definitely likely to exist between a dev kit and production hardware. That’s not the case for most software though.

            And yeah completely agree qualification should happen on a final version, you’re not going to waste time doing that 10 times with each beta, especially when you’re not sure if a bug might just fix itself if you wait and do nothing, instead of having to find a workaround.

            That’s not what I’m calling out, I’m calling out inertia in the face of *announced, intentional, documented breaking changes which Apple is obviously not going to go back on in the final version*

            I don’t see an excuse not to get ahead and start working on those asap, because they’re clearly not going away.

            e.g. “At WWDC in June, Apple mentions that API X, which was flagged as deprecated last year in favour of API Y, is now gone for good in the new OS. Or that API X now behaves slightly differently in situation Z, and that was not previously announced.
            Audio software developer who already ignored the deprecation notice last year does nothing until release day, then goes “OMG this is a ton of work, they’ve completely removed API X ! Guys, hold off upgrading !”

            THAT is taking the piss in my view.

        4. @reno: Throwing in the word “fact-checking” seems to be required these days in order to avoid any criticism, because who would oppose “facts”. LOL.

          Just in case you are interested in other opinions, here is mine, being a beta tester for some of the big companies in this market. Many have indeed started to work with the transition kit, but each and every macOS beta broke something which tended to work in a previous beta. So devs just gave up, because it does not make any sense at all to work around bugs just to see that the next incarnation has fixed a few and introduced others. And they also have other platforms to maintain, so obviously they would concentrate on other OSes which are not in beta and work as expected.

          Having been with Apple since the very first Macintosh, this yearly race for new OS versions is frustrating to say the least – especially given that support for older versions is rapidly canceled. And of course, everyone of the older guys remember previous CPU transitions (Motorola > PPC > Intel). They were not funny and I still have a hard drive full of apps which I had purchase but were abandoned during these transitions because smaller companies did not have the manpower to get things done.

    2. While dev kits have been available since june, I think there was an assumption that the move would be a little slower. I.e. there would be a single product in the lineup that used them and then over the next 3-5 years it would take over the full product line. Other changes have happened at a much slower rate, so the fact that they released a mini, a macbook air, and a macbook that all use the m1 all at the same time took a lot of people by surprise.

      1. Hmm maybe the surprise was 3 different computers, but all of the rumors pointed to at least the entry level Macbook Pro by the end of the year. Tim Cook also explicitly announced during the June keynote that the whole hardware transition would take 2 years.

        In any case, the complacency of audio software makers wrt macOS updates doesn’t date back to this transition, sadly.

  5. I’d love to hear from some developers how much work their porting takes. How often/when is just recompiling enough? Massive X, for example, uses Intel’s AVX instructions but most developers are probably not doing that, or at least not extensively, so recompiling should go most of the way. Are their toolchain hurdles for recompiling? Bugs after recompiling? Etc.

    1. The saying goes “there’s no such thing as portable software, only software that has been ported” – and that’s going to hold here, for lots of reasons, but most of all, proper audio DSP programming is highly optimised code, typically multi-threaded, with plug-ins running in unreliable environments with buggy interfaces. Ultimately you won’t know it works until it’s been tested & stress-tested & tested in the field in conjunction with other plug-ins etc. That’s going to take a while…

      1. None of that “highly optimised” audio DSP code particularly relies on OS APIs though, especially for software that also exists on Windows. And threading APIs don’t tend to change very often.

        If something like “CleanMyMac” (which IS very prone to breaking with new OSes, because it messes with them at a low level) can get updates for the new OS in a matter of weeks during the summer, I don’t see an excuse for Native Instruments & others to not at least *start* identifying any API changes and any work to do (there might not be any some years) as soon as the beta gets released.

        Officially supporting the new OS is another matter, but really if you’ve done your job well, all you should have left to do on release day is testing & certification on the final version. All of the heavy lifting should be behind you.

        But when you have customers that don’t know better and side with you when you tell them “Apple broke stuff it’s gonna take a while to fix”, why bother ?

        1. if you think that ‘CleanMyMac’ is on par with DSP code, or that changing a processor results only in OS API changes for threading, I question what software dev your 20 years experience is in precisely?

          How do you know what work these companies are doing, behind the scenes, to get going with apple’s buggy OS and their 2018 ipad A12 dev transition kits?

          1. I didn’t write any of the things you mention. You either misunderstood or are making a strawman argument.

            I said ‘CleanMyMac’ has infinitely more touch points with the OS (and thus potential for breakage) than DSP code which is a portable and computational task, whose core implementation can even be shared between Windows/Mac versions.
            Whatever you think of which one is harder or more “elite” to write is irrelevant to that fact.

            Of course there’s more to a plugin than DSP, but Apple doesn’t revamp CoreAudio or other Frameworks every *single* year, and if you practice good code hygiene and act upon deprecation notices before the very last minute, you’re mostly fine.

            Regarding CPU arch changes, I simply said that you could catch anything related to that with the A12 dev kit just as well as with the production M1s. And that it’s an overblown concern for most devs in 2020 anyway, unless you’re handwriting assembly like it’s the 80s (I accept that DSP *might* be one of the few valid use cases for that)

            So yeah, the CleanMyMac guys typically have a bigger job on their plate each year than your average plugin or DAW dev, but strangely they get on with it asap and usually release a few updates over the summer, and are always ready on day one.

            This isn’t at all the attitude I’m seeing in the audio software industry, from different online conversations, the tone of their customer warning e-mails, and interactions with support.
            Again, nobody’s going to blame a one man shop if they’re not ready on day one.
            You could blame them for not even *trying* though, and talking to their customers as if the new OS was an unknown Apple trade secret until release day. That’s just insulting our intelligence.

            1. > I didn’t write any of the things you mention. You either misunderstood or are making a strawman argument.

              > So yeah, the CleanMyMac guys typically have a bigger job on their plate each year than your average plugin or DAW dev, but strangely they get on with it asap and usually release a few updates over the summer, and are always ready on day one.

              I will have to directly quote you here.

              Quote myself (almost prescient of the above, no?):

              > if you think that ‘CleanMyMac’ is on par with DSP code, or that changing a processor results only in OS API changes for threading, I question what software dev your 20 years experience is in precisely?

              > How do you know what work these companies are doing, behind the scenes, to get going with apple’s buggy OS and their 2018 ipad A12 dev transition kits?

              again

              > That’s just insulting our intelligence.

              You haven’t a clue, and another 20 years experience won’t get you one either, given the above reading comprehension issues. It’s funny how many people can write walls of text and fail so utterly at reading.

              Seeing as you expect me to have read all your other walls of text up thread and are now referring to them, this is facepalm stuff:

              > You could have had your ARM dev kit since June and have solved 100% of architecture-related issues with it *just as well* as you can do with a production M1 today.

              Go get yourself a real programming job kid

              1. The fact that you insist on your shoddy paraphrasing being an accurate representation of my point in any way, and that you simply repeat it a second time in lieu of a proper argument, is an indication that you lack either the basic software development knowledge or the logical reasoning skills required to distinguish between what you claim I said and what I actually said. Both would disqualify you from the discussion (and from any senior programming role btw)

                Your point consists of naively thinking of DSP programming as some kind of noble black magic art compared to the lowly pursuits of OS maintenance software. When I call your BS and get into details of how relevant each of these is to OS upgrades, you just repeat the same thing and resort to insults.

                > Go get yourself a real programming job kid

                Happy to compare CVs ANY time, troll. Careful, it will burn 😉

                1. DSP runs on processor, the processor changed, a lot more than just the OS APIs changed. You basically ignore this.

                  I stated you think that the challenge in getting a CleanMyMac program going on a new OS is on par with the DSP challenge. You then go on claim this is a straw man, and then later say exactly what I accused you of. You think that the OS change is the problem, not the processor change.

                  You haven’t called BS on it all and in fact you make my point for me here again, you think it’s the same. You are re-iterating this again. Why deny at any point that you think it is of equal difficulty? No straw manning here.

                  I don’t care to compare CVs with someone reliant on CleanMyMac software, nevermind one as ignorant as you.

                  You have no idea of the work going on to get these chips going. If you think it’s ‘overblown’, I sincerely advise you to use VCV rack as a barometer of how much is involved, it will be an eye opener.

                  1. I’ve reread the thread and the misunderstanding is because we’re talking about different things.

                    You’re focusing on the processor ISA change. In all of my comments I was broadly calling out the audio software industry for systematically ignoring the macOS beta period every year, and trying to get away with it by gaslighting a largely non-technical and gullible customer base.

                    In that context, damn sure, the CleanMyMac guys typically have it WAY harder with new OS breakage in any given year than you guys in the audio industry (which I assume you’re in, since I seem to have struck a nerve so hard)

                    Yet these guys don’t look for excuses and start the work immediately each year (great piece of software btw, you should try it. It’s like a dishwasher : I have zero shame relying on it because I have much better things to do with my time. Don’t you ?)

                    Do you see how that’s not a statement on the relative difficulty of porting DSP code vs OS maintenance software to a different processor ISA ?

                    It’s a statement about complacency.
                    I understand the hardware guy elsewhere in the comments who won’t start final QA with pre-production machines. That makes sense.

                    If you’re a software guy with handwritten x86-64 assembly all over your DSP code (ever heard of compiler intrinsics btw ?), what the f*** exactly were you doing since WWDC in June ?
                    Heck, I would have started rewriting my non portable hacks as soon as the ARM Mac rumors started at least a year ago…

                    Do you guys secretly hope that kind of massive, announced change is gonna magically go away between June and October if you close your eyes and wish for it really really hard ? lol

                    Let’s talk about that if you want. Tell me which items in there apply to your code, I’m all ears :

                    https://developer.apple.com/documentation/audiounit/porting_your_audio_code_to_apple_silicon
                    https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code

                    And most importantly : what exactly in that list can you do now on an M1 that you couldn’t do on the A12-derived dev kit CPU ?

                    1. You then:

                      > If something like “CleanMyMac” (which IS very prone to breaking with new OSes, because it messes with them at a low level) can get updates for the new OS in a matter of weeks during the summer, I don’t see an excuse for Native Instruments & others to not at least *start* identifying any API changes and any work to do (there might not be any some years) as soon as the beta gets released.

                      > You could have had your ARM dev kit since June and have solved 100% of architecture-related issues with it *just as well* as you can do with a production M1 today.

                      > None of that “highly optimised” audio DSP code particularly relies on OS APIs though, especially for software that also exists on Windows. And threading APIs don’t tend to change very often.

                      > ‘CleanMyMac’ has infinitely more touch points with the OS (and thus potential for breakage) than DSP code which is a portable and computational task, whose core implementation can even be shared between Windows/Mac versions.

                      You now:

                      > You’re focusing on the processor ISA change. In all of my comments I was broadly calling out the audio software industry for systematically ignoring the macOS beta period every year, and trying to get away with it by gaslighting a largely non-technical and gullible customer base.

                      > Do you see how that’s not a statement on the relative difficulty of porting DSP code vs OS maintenance software to a different processor ISA ?

                      I’m just repeating myself at this stage, you write and write but you don’t even read what you write. You seem to forget.

                      if you think 1) that this hasn’t been worked on since day one (like every year, you seem to have no idea the level of breakage macOS betas go through)

                      2) ‘compiler intrinsics’ (hint: they are not portable across architectures) and that skimpy Apple doc are enough to get what you suggest done in the time frame you suggest, you are hopelessly naive on both counts.

                    2. You keep pasting my statements next to each other as if they were in contradiction, but they really aren’t. If you’re doing this in good faith that’s an embarrassing display of sloppy logic for a developer. I’ll go through each of them and that will be my last answer.

                      > If something like “CleanMyMac” (which IS very prone to breaking with new OSes, because it messes with them at a low level) can get updates for the new OS in a matter of weeks during the summer, I don’t see an excuse for Native Instruments & others to not at least *start* identifying any API changes and any work to do (there might not be any some years) as soon as the beta gets released.

                      Indeed. Emphasis on *start*.

                      > You could have had your ARM dev kit since June and have solved 100% of architecture-related issues with it *just as well* as you can do with a production M1 today.

                      That is absolutely true if we’re talking about software and porting to a different processor ISA. I later found out that the guy I was replying to was on the hardware side, and acknowledged that it is different.

                      > None of that “highly optimised” audio DSP code particularly relies on OS APIs though, especially for software that also exists on Windows. And threading APIs don’t tend to change very often.
                      > ‘CleanMyMac’ has infinitely more touch points with the OS (and thus potential for breakage) than DSP code which is a portable and computational task, whose core implementation can even be shared between Windows/Mac versions.

                      That is also true. Again, so true that these core DSP functions can and should be shared across Intel code bases.
                      Actually, if you’re making a plugin and are as senior a developer as you think you are, you could also have made plans ages ago to make this architecture independent so your company could offer it as an AUv3 iOS plugin.

                      Having portability in mind is just good programming practice, so is making a *plan* to move off deprecated APIs as soon as it’s announced (emphasis on *plan*, lest you accuse me of being naive), not just when you’ve got the gun to your head.

                      That’s basic tech debt and software project management, and those who embraced this are reaping huge benefits right now.

                      You can decide to be that kind of developer, or you can keep whining forever about how evil Apple is for breaking your dodgy hacks or (like the whole audio software industry did with Catalina) being up in arms because they were finally deprecating 32-bit code with 2 years notice, 11 years after 64-bit was a thing on OS X.

                      And you guys then have the nerve to try and get customers on your side and blame evil Apple for that shitshow ? Give. Me. A. Break.

                      > You’re focusing on the processor ISA change. In all of my comments I was broadly calling out the audio software industry for systematically ignoring the macOS beta period every year, and trying to get away with it by gaslighting a largely non-technical and gullible customer base.
                      > Do you see how that’s not a statement on the relative difficulty of porting DSP code vs OS maintenance software to a different processor ISA ?

                      As shown above …

                      Now, if you’re telling me you :
                      1. Watch WWDC every year
                      2. Make note of any *announced API changes that are not gonna magically disappear between now and release day* and start working on what may impact you straight away.
                      3. Have at least tried a build on the new OS by July to find any low hanging fruit that’s easy to fix right now, and plan the rest.
                      Then great, I take everything back.

                      That is certainly not the impression I get from various conversations, including this one.
                      That is certainly not what’s communicated to customers. I once asked about compatibility of an audio driver with the upcoming OS in September and got : “this is an OS that doesn’t even exist yet and that nobody knows about. We’ll update you when it’s here and have had a chance to try it”. JFC…

                      Look, I know Apple developer documentation is notoriously terrible, partial, and out of date.
                      Again :
                      – Not starting full QA until the GM or even final release is here : fair enough.
                      – Pausing your work when you encounter a new API/subsystem not behaving as it should and you suspect the next beta will fix it : fair enough.
                      – Noticing an announced deprecation and procrastinating until release day hoping it goes away, or not even trying to build on the beta OS over the summer : that’s unprofessional and not fair on customers. You’re not taking the chance given to you to get ready earlier. Don’t complain when you’re called out on this.

  7. Been testing a number of things on my MBAM1. Even with the internal soundcard, using third-party apps and plugins meant for Intel chips (e.g. Chromaphone 3, Bitwig Studio 3.3, Pigments 2…), I can go to 96kHz with a buffer size of 32 and get a smooth experience while running multiple apps in the background. (I sometimes notice 16 frames available as a buffer size, but it doesn’t stick.)

    To me, it’s not about how impressive it is. It’s just plain satisfying. I’m coming from a 2012 MacBook Pro, so no surprise that there’d be an incredible improvement. Well, it could be a surprise if you thought that the Rosetta 2 translation layer is in the same order of magnitude in terms of power as emulation. It’s not. Rosetta 2 is remarkably powerful. Nothing to do with emulation, in terms of performance.
    And it runs just about anything which isn’t artificially blocked (Native Access prevents me from installing anything from Komplete though I’m sure the apps would be fine). One exception is with most AIR authentication software. For some reason, it just doesn’t run and it doesn’t sound like it checks for the processor. (iLok works fine along with Wave Central, Arturia Software Centre, etc.)

    What’s less satisfying is the situation with AUv3 plugins from iPad or iPhone. Standalone apps from iOS/iPadOS typically run fine, apart for GUI issues because they were designed for small touchscreens. Most AU MIDI plugins are in the same situation (run well with weird GUI). AUv3 synths and FX are really a mixed bag. Many devs have opted out of the Mac App Store. The AUv3 plugins which are on the store (including VirSyn’s AddStation which explicitly mentions M1 support) can be difficult or even impossible to validate, may not load properly, might crash the host… It’s pretty messy.

    There’s a loophole to access any app associated with your Apple ID, even if devs have opted out. Ethically, it’s a bit iffy and it’s quite possible that Apple will soon close that loophole.
    Still, because I’m a researcher, I’ve been testing those as well. In some cases, they run more smoothly than the apps on the Mac App Store. None of them works perfectly and it’s a time-consuming process to wade through all of them. In fact, I’m getting a hunch that it might go to a level of incompatibility between them as a plugin might work great at one point and fail completely if I rebuild the Audio Unit cache and load another plugin before that one.

    I haven’t found an AUv3 which records its parameter automation. They do respond appropriate to automation lanes, but twiddling an on-screen knob while in automation “Touch” mode doesn’t record anything unlike macOS-native Audio Units which record everything, across multiple lanes.

    When Apple announced that iPad and iPhone apps would work on “Apple Silicon”, they overshot, for a variety of reasons. Even the apps they showcased at the M1 launch don’t work well. They never promised that AUv3 plugins would work and I pretty took for granted that they wouldn’t. So I can’t say I’m disappointed. In fact, I feel like this is a great opportunity to test a number of things. Eventually, I’d like to co-develop apps and plugins with diverse people.

    I’m not a coder, I just dabble in code. The M1 makes me want to put serious effort into serious coding.

  8. Impressive, but as an iMac adherent, I like the monitor and powerful Harmon Kardon speakers in one box, not to mention at least some upgradability. Its fair to be boggled at so many instances of Diva, a known CPU eater. Its probably wise not to plan for this to run Komplete and Omnisphere, but its no bum, either. It bodes well for starship-level performance in larger, pending models. I also liked “Yay, I broke it! I feel proud!”:D

  9. It’s good to know that America is great again on making processors.
    It was really a pity for the best computer in the world to depend on foreign capacity.
    The ARM Apple in house processor is not only great or our computers, it is great for our country.

  11. These are the worst Apple Silicon Macs that you will ever see.

    It’s perfectly reasonable to expect double the performance of these machines when they introduce the high end MacBooks, and at least four times the performance when they intro the new Mac Pros.

    Apple just jumped WAY ahead of the Wintel platform.

    1. Wintel is only a marriage of convenience. Microsoft has every major revenue source ported to any relevant processor on any day of the year. Nobody is caught off guard by processor changes anymore. It’s the performance tweaks and processor bugs that take time to prove on a commercial OS.

      Intel is the loser here. But certainly they saw it coming.

      1. There won’t be M1 PCs, though, and the M1 Macs just completely blow away the performance and battery life of Intel laptops, even fairly high-end ones.

        Microsoft will always sell more office licenses, but can anybody argue that a Wintel PC makes sense when cheap Macs blow them away, are priced competitively, and will run two days on a charge?

        2. Office is a cloud app now. I can run it on my iPad. Intel will protect it’s CISC market, and introduce RISC competition. Processor ISA turnover is part of the business, nobody is severely inconvenienced by this anymore.

          I prefer RISC, it’s a better for step and repeat scale-out processing. Clocking is always the issue with modern silicon.

  12. Oh look RISC is back again, and CISC is out again. With will MIMD, SIMD, and Systolic arrays are right around the corner! No doubt!

    When will computing be interesting again? The whole Wintel/Linux/OS X thing has been an endless monotony of piddling incremental nothingness for so many years…

    1. “ When will computing be interesting again?”

      A 3x-4x year-over-year performance improvement, for the same price, isn’t interesting enough for you?

      We haven’t seen this sort of performance gain ever. What would it take to interest you?

  14. It’s funny that Nick didn’t disclose the fact that any iOS app can run on M1 based Macs.
    All you need is… Sorry, I’m under NDA and can’t disclose that, but google is your friend ?
    Currently running all my iPad music production apps on M1 mini with no issues whatsoever- 155

  15. All of this hollering is why my instruments are mostly native Logic. I added some 3rd-party pieces after seeing a company and its reviews remain stable for a while, although you have to build slowly. I like better speed & more memory, same as you, but I get the feeling some of you live in a world of overload. How many devices are you mad men running at once?? 😛 Synths fill the spectrum quickly. If you’re running 90 tracks at once, you’re either Pink Floyd or anal-retentive to the bone.

    1. A base Mac mini costs $699. An Intel or AMD Processor that matches the M1’s performance is over $300. Add a $100 motherboard, cheap $79 case, $49 power supply, $50 SDRAM, $80 SSD and a cheapo $50 video card and you’re at $708 for a meh machine running Linux or a pirated copy of Windows.

  18. No, because Microsoft’s “backwards compatibility first” approach comes at the cost of innovation.
    I prefer Apple’s “fast moving even if it leaves things behind” philosophy, and the benefits of this platform to me vastly outweigh the inconvenience of some of the software I use taking a while to update (mostly just audio software)

    But to each their own !

  19. I’m interested in a dedicated system to do basic video editing. I think something like this – coupled with some larger storage could be really cool. What do you all think??

  20. I traded up my 2016 MBP for my M1 MBP. So I got the 16 gigs of ram and 256 HD for just over $600.

    Insanely fast. Very fast. And only 88% battery after a 1 1/2 hour Ableton session and a half an hour video editing and rendering session. 88%. That’s eighty eight percent. My old MBP would have been dead @ 45 minutes.

    Impressed is an understatement.

    Now if Serato would update their DDJ-1000srt driver ……

  21. I would get an M1 Mac Mini but with 16gb ram so the page swap dont kill the storage life. Remember this is all soldered in the same die so the malfunction of one component is the death of the whole device. I’ll be checking for deals but if nothing appears I’ll wait for the M2 Mac Mini.

Leave a Reply to elwyn Cancel reply

Your email address will not be published. Required fields are marked *