The impact of Apple Silicon Macs on Broadway
brianli.com
brianli.com
That said, 4-5 years down the line when this whole transition is over on macOS, it's going to be great. And for anything not relying on live synth/processing, you don't need many/any plug-ins at all, so that'll work well today.
Personally, I'm really looking forward to doing real-time / live audio set-ups on my M1 Macs under Linux as soon as next year. The design of the M1, beyond just performance, is almost certainly much better than any x86 box for real-time processing, and likely capable of much lower latencies (due to x86 junk like SMBIOS and their power management approach killing worst case latencies; x86 can't match ARM embedded systems for real-time stuff, but M1 is from the embedded world). And since it's Linux, all the open source stuff is already ported to ARM, and the wine hack I use to run a few Windows VSTs ought to be compatible with shoving them under qemu-user without disturbing the rest of the set-up.
Having said that some consideration to keep in mind:
- audio code needs to be optimized for real time thread constrains. Many optimizations usually made by vectorizing rather than threading that would've lead to locks and synchronization not always possible for real-time processing. So not all SIMD code can be compiled just by changing a flag.
- machine specific code. While rare. Some companies still got such code for various reasons. And needs more complex transition.
- Not all companies were able to obtain DTK. We for example, got our first M1 machine 3 weeks ago.
- Backward support. While we'd like to have universal builds, musicians use their systems for years. We still support 10.7. With Big Sur Apple seems to break SHA1 signs making builds from Big Sur work reliably only on 10.11 or newer. (The first release to support SHA256 codesigns)
- some companies already got Universal builds. REAPER, FabFilter and Adobe Audition are few I can remember.
Keep in mind electron, docker, Homebrew and even other "devs" tools still not fully Apple Silicon ready.
So indeed the above statement is unfair for a small industry (vs finance or other software markets)
Affinity Photo is an Arm/Intel universal binary that’s also compatible with OS X 10.9. Maybe look into what they’re doing?
2. We've been able to input down to 10.7 and didn't see any issues. The issue is productsign/codesign linking Security.framework which I assume changed.
Is this your personal experience or are you speculating? I haven’t noticed performance drops or stability issues under Rosetta so far. A truly impressive feat of software engineering.
Let's say you have a DAW with ARM and x86 binaries but a VST/AU/RTAS that's x86 only. You need to run the DAW as x86 under Rosetta, which will result in reduced performance versus a native binary, assuming the native processor was capable of equal performance.
Given how zippy the M1 is, that performance penalty may well still put you ahead of where your x86 perf was, but still slower than native.
I'd personally be more concerned about stability and drop-out issues. Apple sells Rosetta as an "ahead-of-time" translator, but that is necessarily best effort (because true transpiling is not a solvable problem, e.g. self-modifying code). Thus, there is always the possibility that the JIT gets invoked in the middle of the audio processing thread, and that won't end well for real-time guarantees. There are also programs that just don't work under Rosetta properly (for unclear reasons).
Also, audio companies sometimes like to use "fun" DRM/copy protection systems.
Besides, audio apps themselves doing JIT would not be unheard of. For example, that'd be a very efficient way of implementing a modular synth. Those apps could JIT in a realtime-safe way; Rosetta can't (it doesn't have enough info).
You responded with some technically-detailed speculation, which, fair enough. I guess we'll have to wait and see.
Switching to x86 emulation for compatibility, will be a performance hit against running native ARM
The arguments in the thread about "but a lot of software right now runs in emulation" and "who knows when the software companies will get around to transitioning" aren't wrong, per se, but they're also arguments that long-time Apple users have heard variants of in the PowerPC to x86 transition. And in the (original) Mac OS to OS X transition. And in the 68K to PowerPC transition. It turns out that when transitioning your software to the new platform doubles your performance and/or is necessary to keep selling your product, you have a fairly strong motivation to do the work.
Doesn't Logic Pro already support this?
Admittedly it does mean the plugin runs in a separate process&thread, requiring IPC to render each chunk of audio through that plugin.
It does. Apple provides all AU hosts ability to run Rosetta2 AUs in native DAWs
See here for why that doesn't scale to serious productions with high track count:
It didn't support it during the 32/64 bit transition, don't know about Intel to ARM. Of course even if Logic does it, there's the other DAWs.
VST2 is probably doable - what I use to run Windows VST2s on Linux is something similar with an out of process wrapper - but I can see VST3 with its C++ API being a major, major pain in the ass. And even then there are downsides. Running plug-ins out of process has significant context switching overhead. It's fine for one or two or half a dozen, but compare running 50 plug-ins in process and out of process and you'll notice a massive performance difference. You can fight that with larger buffer sizes, but that adds latency.
Remember, DAW deployments are not actual hard realtime. If you drop one chunk of samples every night, no one cares.
[0]: https://www.osadl.org/Latency-plot-of-system-in-rack-c-slot....
[1]: https://www.osadl.org/Latency-plot-of-system-in-rack-0-slot....
Have there been stability issues with Rosetta? I haven’t seen reports but I’m not switching right away so may not just be looking closely enough.
There are ways to bridge it but basically you have a native plugin shim that talks to a process running the target arch and essentially passes protocol messages back and forth. Was common for a while on windows when many plugins were 32bit only and wouldn’t run in a 64 bit host
Let's assume an ideal implementation where there is only one process per architecture. Take a 100 track project with two plug-ins per track (say, compressor and EQ). If the compressor is x86 and the EQ is ARM, that's 200 context switches per audio period. That makes it impossible to run at small buffer sizes. A very smart flowgraph implementation could attempt to batch everything into the minimum number of context switches, but that has other problems with threading. It's very hard to get this perfect.
This solution works fine for when you just have a few straggler plug-ins of the wrong architecture, but it would still require quite complex engineering by the DAW to make it work transparently to the user. Consider, for example, that the plug-in UI needs to embed in the DAW across a process boundary.
There are alternatives, like the bridges mentioned by the sibling post, but it's clunky and manual to setup and slows down your workflow.
Why is it their responsibility? Apple has literally billions in the bank, they should be running an incentive scheme if they want more native ports.
This reminds me of people complaining that Docker doesn't run on Apple ARM yet. Why should it? Apple are the ones that changed the architecture.
If Docker didn't support Apple devices going forward, they would lose a significant amount of users.
If Apple doesn't support docker going forward, they lose a tiny percentage point.
That being said, its mutually beneficial, so Apple should be putting their best effort to making the transition smooth (which I think, at least from an outsiders perspective, they are)
Apple didn’t kill Flash. Adobe did.
By failing to deliver a performant and secure version of Flash (under any architecture, but especially mobile), Adobe ensured Flash would be not be viable for the web as it evolved.
At this point, at least, I'm pretty sure WebGL can do most or all of what you could do in Flash. It's possible that the tools have never caught up, but it also seems possible to me that the space that used to be occupied by Flash games has largely been filled, ironically, by mobile gaming.
Youtube was completely built around Flash, the FLV format hit a sweet spot between "not looking like trash" and "not needing more bandwidth than the average user had" that else had before. I'm pretty sure we would be seeing a shit-ton of people filming themselves talking to the camera even if Flash was still a going concern - animation is a ton of work.
Youtube exists because of Flash. They were are the right time and place to have a flash object sitting on a webpage that could play video in a reasonably cross platform way.
Not sure this is entirely due to the flash web player being phased out. Kids just watched their friends play from the couch, or watched more generic broadcast television. Now they still watch and play together but remotely.
Edit: 'due' not 'sure', 'play' not 'pay'
Are they? Maybe in HN's niche community—and it is niche—but I suspect the vast majority of Apple's customers don't remotely associate web developers with the brand.
They demoed Docker on stage at WWDC. They've donated equipment to Docker. Apple built a significantly better virtualization framework for Big Sur/ Apple Silicon.
What makes you think they don't care about it?
This transition is in baby steps right now. It takes time to migrate software.
And even if we over come all those hurdles we still have to convince the avg joe to adopt them too otherwise it will just live in a small costly niche that the wider community just don’t bother supporting.
All we can do is try and pick the least abusive relationship we can afford and is practical to run.
My point is, I don’t it against people for using platforms others may find abusive. Sure us on HN are more likely to be in the position where we can switch platforms for fun just to see how they work out. But for most they simply don’t have the time or patience to swap and learn a new platform (let alone the cash).
Maybe this is a bad example because of what exactly happened with one manufacturer, but it’s why airlines like plane manufacturers to not go too far with design changes because it requires them to retrain their polits on the new aircraft.
If every time you purchased a new car you had to take into consideration that the control system was different between each manufacturer which may even require you to retrain in order to drive it you may very well consider with sticking with what you already know.
So I don’t hold it against anyone who simply wants to keep with what they know. They just want to fire up the platform at get to using it.
Anyways sorry for the rant, just my thoughts on the matter.
That way we don't duplicate effort for an ever closing dictated by one greedy body.
> Why is it their responsibility? Apple has literally billions in the bank, they should be running an incentive scheme if they want more native ports.
Because they want to sell software and/ or hardware.
> This reminds me of people complaining that Docker doesn't run on Apple ARM yet. Why should it? Apple are the ones that changed the architecture.
Docker is getting migrated for the same reason it was originally ported to MacOS. Because the developers either run Macs or work for companies that support people who run Macs. It's the same reason any software is getting ported.
I fondly recall how a good friend of mine was impressed by the compute performance of the Apple based workstations at her university. I convinced her to get a PC for the same cost as the Mac, and then she complained how slow the university Macs suddenly felt. (That was ca 2014).
I set up a VR performance in a gallery once. It was supposed to run the same piece of a basic program for 3 months.
Since it was Windows we had to do additional steps to make sure that it wouldn’t try to update* and possibly break drivers. Because there wasn’t IT staff around to fix things if it broke down.
I never had such issues with MacOS.
* - additional steps like making sure the built-in wireless is disabled and it doesn’t remember any wifi passwords, so it doesn’t try to fetch any sort of update. Because even if you disable Windows updates, you have a bunch of other drivers that may ignore those settings. And then, if we needed to put anything new on the computer, we had to either use usb-sticks or break the airgap and redo all the testing - so it had to be timed so that we would have at least half a day to fix it if broken.
My concern is that as a fallible lil' human, and moreover one with autism, I find it probably more upsetting than most to have stuff randomly break for no reason. I depend on continuity and repetitiveness to be well. As such I try to operate on computer systems that don't change out from under me at someone else's whim, because I can be thrown into the inability to function, by something at an unexpected level of abstraction blowing up.
This most recently happened under OSX Mojave when my (non-Apple)_apps could no longer check with the authentication server and would not launch. I lost a day to trying to repair my system: Apple had never told me 'by the way, everything you run now has to talk to a server of ours or it'll refuse to launch'. I disabled the functionality, but I can't have things like that going on. It makes Apple the cyber-terrorist they are trying to 'protect' us from.
Again, I understand their motivation as they are a titanic collective entity trying to administrate and tend another titanic collective entity, their userbase, which they feel is a part of themselves.
However, as a lil' human type, I am too deeply committed to maintaining usefulness for lots of older computers owned by other lil' human types, many of whom can't consistently throw thousands of dollars at Apple to stay in the ecosystem as Apple understands it. I find Apple's actions morally reprehensible (granted, among the least reprehensible actors in the world of computers and internet, but still)
Windows 10 LTSC is a good fit for this type of scenario.
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/l...
Posterous - oh no! ;) Perhaps I will change the link to the webarchive page of it :)
I am not a professional, so I might not know audio stuffs. But manual Windows Updates is easy.
Directed at you: I would try to avoid such software, and look for alternatives. (I expect this to be futile?).
x86 is available across the world as well. Others already pointed out comparable form factors.
Also, computerhardware reliability is pretty good these days. Maybe you could set up a scheme to reuse your tech stack?
On the extreme end, server hardware can run for years with 0 hardware-related downtime (and offers nice things like redundant power supplies, 19" rack cases [but much deeper than audio stuff?]). And brutal performance: Even my 450 Euro used&modified (new nvme disk, faster CPUs), 5y old, 1u(!) Intel dual socket system can mop the floor with most desktops below a Ryzen 3900 (at least on my compile workloads, and on anything that swaps on less than 128GB RAM in general).
They don't run macOS, so won't run your software though.
So not an intel nuc then, which is what I was specifically referring to.
Also, while a lot of people use Pro Tools for recording/mastering Ableton (which are cross-platform) for live stuff, lots of shows use Mainstage which is Mac only. Logic is really good for recording and sequencing too and also Mac only.
I have a small story to tell about this. Windows WASAPI has a way for it to tell you when, supposedly, the endpoint device started the recoding of a buffer. This is important if one wants to have a sync with precision of sub millisecond range.
Well. It doesn't quite work like that in reality. I noticed the hard way that if one gets a 2ms long packet. Queries the high performance timestamp, then queries the packet recording time, then queries the timestamp again. The packet was supposedly recorded after the first timestamp but before the next. And as the packet was 2ms long and the previous timestamp was way way way less than 2ms from the query it means that it was impossible for it to start the capture at that point.
So instead of returning the start of the recording as per docs state WASAPI just returned the current high precision timestamp. It's basically you asking someone "Hey, this 10 hour video you gave me, when did you actually start recording it?" "Now. I started the recording right at this moment".
This story has a happy ending though. I grabbed portaudio, hacked it's windows low level implementation to return the actual timestamp based on the register of the soundcard that points to the FIFO buffer and managed to get sub ms precision.
So if macOS audio API's are as good compared to Windows (which is a dumpster fire unless one uses some custom stuff dependent on manufacturer) as iOS api's are compared to Android (where only Pixel phones are not dumpster fires) I can easily see why Macs are the devices of choice.
Obviously it's not Broadway but I ran the sound for school productions for years, and we were able to quite happily do (increasingly DSP based as the years went on) live audio I/O on literally the worst windows machines you could imagine.
The whole idea that the OS really makes any difference - especially for being "creative" is just a placebo.
If Mac APIs actually work as advertised then the difference is that windows programs work weirdly (bad sync etc) or have had to spend tons of time making custom code to workaround the badness of their ”professional” audio API, costing way more.
And another example is Android. It’s definitely not placebo that it tends to have horrendous latency. Originally due to design and nowadays due to bad vendor implementations with only Pixel phones reaching iPhone levels of latency. We’re talking about latency in iPhones being only few ms and tens of ms or even more in average android phone. That does actually matter in music production.
My own concern is watching Apple pursue a path of driving upgrade purchases through (A) increased performance and (B) breaking older systems or (C) disqualifying them from use of current software.
C is easy and practiced intensely by Apple, which abandons support for older stuff VERY REGULARLY in XCode. This may or may not be better than allowing it to rot and become deeply broken through lack of maintenance, but it's a choice and Apple repeatedly chooses to throw away even the possibility to support older machines.
B happens through rot: things get complicated, and if they don't care what happens to you AND they are changing your machine out from under you, they can just randomly brick it one day and not be a bit sad about it. It was your fault for not buying newer things, regularly.
A is also something Apple's been capable of. You buy into that and if you stay on the bleeding edge, Apple's become pretty good at keeping you riding that wave of the best computers can do, at any given moment. This also (to some extent) helps the older stuff become more affordable as it's left behind: that's positive in its way. 'Bleeding edge' is not the only kind of functionality to have. I've noticed that for music production testing of Apple Silicon, all the test cases are completely unrealistic: 4000 tracks each of which has 10 Space Designers, etc etc. That means the use case is a solved problem: you don't need the new Mac to do it, at any reasonable level. 8K feature film video on the desktop, yeah you can still need bleeding edge for that. Music, no, not at all.
This is also why it's important that Apple not break its own APIs or let them rot. On the whole, the functionality just works, every time, no matter what. This is a serious thing to risk by allowing the platform to become less reliable due to needing to 'churn' it and sell new generations of machines.
Today, for a proper answer I'd had to check specific benchmarks and compare prices. If noise is no problem (e.g. separate tech room backstage, where the power amps live) used server hardware could be a reliable and performant option on the cheap.
If they made a smaller and much cheaper entry-level Mac Pro that had a rack mount kit to fit in 2U or something, that would be amazing for production.
Click the “Buy” link: https://www.apple.com/mac-pro/
They fall for marketing significantly easier and use Veblen goods to signal wealth and power.
Then they get used to a system and it's all they know. It's more effort to change and they get locked in.
Software engineers are forced to use tradition and Authority due to abstraction.
I say this as a programmer.
It's absolutely standard for electronic musicians to bounce tracks with computationally expensive plugins to static audio tracks while working. Otherwise, there is usually not enough CPU available to perform all the DSP for a complex song. (Additionally, bouncing tracks to audio gives more control over fades, cross-fades, tails, etc.)
This blog post confuses me, because is he playing the VSTs live? Why not trigger bounced audio instead?
They may not always be performed exactly the same way ... with the exact same timing or at the same tempo or the same pauses, etc.
These days everyone expects to be able to just layer on 8 effects on every track but.. that's a pretty recent luxury. Back when computers weren't really powerful enough out of the box to do stuff like that you could get dedicated DSP cards like Universal Audio's "UAD-1" PCI card, which let you use really high quality effects on your tracks without overloading your CPU. Now they have newer Thunderbolt/USB-based outboard stuff to do the same thing.
Regardless, most people in audio know you never buy the brand new hardware (especially when it's on a new processor architecture) and expect to be able to do everything as effectively before. It takes a while for all the third-party software vendors to update their stuff and make it run smoothly, assuming the software team is still in business or still working on that product. There's a ton of great stuff we'll never get new updates of. This is why you'll sometimes find pretty old computers in musicians' homes... There's still one cool granular synthesis app I can think of for Mac OS 8/9 (th0nk) which was never updated for anything newer, for example.
If they no longer plan to sell or update the software, I wonder what's to stop them from open sourcing it if asked.
(direct download link http://www.audioease.com/download/thOnk_0+2.sit.hqx )
Worse, you also can't know in advance IF your existing hardware will be supported on a new system. That has bitten me once with an E-MU 0404 USB audio interface. The fine folks at Creative never bothered to release a production driver for Vista, let alone Windows 7 or later. Needless to say, I don't buy Creative products after that.
On the Mac side, I could only imagine them getting advance news of the M1 and going ¯\_(ツ)_/¯.
There are some constraints on how much complexity a single machine can handle but MIDI sync, Ableton Link etc. allow to combine multiple computers and hardware synths in one setup.
Anecdotally, I don’t perform live but I write music as a hobby and I rarely if ever bounce to audio to free up RAM or CPU. I do bounce for artistic effect though (such as reversing a drum loop or shifting it up/down an octave).
[0] Like Caribou: https://m.youtube.com/watch?v=8s7Z3vMUGrs
You may say the audience won't know the difference. But word will get out. Audiences may not be willing to pay premium prices for prerecorded content.
Does the potential for failure and variation attract the audience? Or just the fact that the medium is much higher fidelity: stage actors are human, three dimensional, and no other medium can record all the subtleties of motion and expression just as well.
An concert, a play, or any other live performance is much more than a single night, 2 hour performance. It's countless hours of practice, errors, emotional up & downs during the journey.
The performance one watches is the tip of the iceberg and the underlying depth is what amazes us as humans. The unmistakable performance or real-time and invisible improvisation during the show.
I used to played in a symphony orchestra. Even the slowest of classical pieces is a storm for the orchestra, if not for the spectators.
On a side note, these broadway performers and musicians were awesome and incredibly professional and talented. I didn't know what to expect (as a kid, I found these musicals so boring) but it was great.
Ease and quality of improvisation? Does the musician here improvise? Slight variation in each performance?
The main song in Phantom of The Opera, in the West End, is/was done to a click track - and the performance is/was noticeably flat because of it, in my opinion.
Otherwise why not just fire up YouTube out Spotify
There is no real content. No real impact is mentioned.
It says they used Mac Minis which they had to reduce the sound quality to use. OK.
"Apple Silicon changes everything for Broadway electronic music designers. The new M1 Mac mini is capable of running high-end sample libraries and virtual instruments in a stable manner".
That's an output. What is the impact then?
I found it interesting and informative about a part of the world I don't have experience in. If you don't like it, that's fine. Not everything has to be for you.
The only mention was big sample libraries which are not generally cpu bound. If they mentioned 300 note polyphony or analog or physical modeled synths or even mention some of the software used I’m happy to learn. The point is that there is no detail here. I have run daws and pro audio for over 20 years and I want to know details.
https://www.sweetwater.com/insync/audio-networking-explained...
https://en.m.wikipedia.org/wiki/Dante_(networking)
versus the streaming associated with Spotify et al
IOW a legitimate (non—audiophile) piece of gear
Another aspect is that the audio stack on MacOS is truly outstanding, with a whole host of professional audio applications and utilities on the platform. Hardware drivers are up to date and also well supported. Connectivity is also well supported by audio hardware vendors.
Finally Mac Minis have had a stable hardware form factor for well over a decade. If you go for a small form factor generic Pc system there’s no guarantee anything like it will even exist a year or even 6 months later. Hardware specs and specific component choices change with the breeze as availability and relative pricing fluctuate continuously.
> Another aspect is that the audio stack on MacOS is truly outstanding, with a whole host of professional audio applications and utilities on the platform. Hardware drivers are up to date and also well supported. Connectivity is also well supported by audio hardware vendors.
I absolutely appreciate how Macs don't really need you to play with the drivers... I've been using them for years and haven't once needed to do so.
The larger point here is that the M1 is not as revolutionary as it's being made out to be. The "flagship killing" multi-core performance is embarrassed by the Ryzen 4800u, which can be found in NUCs that cost significantly less than the Mac Mini. If price were a limiting factor in the industry, we'd probably see more people reaching for those Ryzen machines: but we don't. That's why this article is ultimately self-defeating.
Sometimes a DJ or bedroom producer is using Windows. So it's quite surprising to hear you say that Linux is the standard.
Can you point me to any producers, artists, sound engineers, studios, or production houses that use Linux? I would love to know...
I have never seen anyone using CALF tools in this profession. Looking at what that does - the functionality is available in a number of rock-solid applications native to Apple (MainStage, Ableton, Logic, etc). So there's no reason why it would need to be ported to MacOS.
How are you measuring audio stack superiority? And in terms of "stack", are you talking about something separate from the suite of professional audio / MIDI tools that come standard on every Apple computer that don't seem to have any comparison on Linux or Windows?
Are you taking into account the availability of hardware drivers on these different platforms? What is your experience in setting up a Linux-based audio production system with a lot of outboard gear? This is one area that seems to be a major source of headaches and motivation to not use Linux for producers and engineers.
Even looking through the comments on this page - there's people talking about the difficulty of setting up a functional audio production environment in Linux compared to Apple. I've noticed this sentiment is repeated over and over again on HN (going back to previous articles on audio production, Ableton, etc).
This topic stands out to me as I've sincerely wanted Linux to be much less of a headache with audio so I can get off the Apple ecosystem entirely.
Audio on Linux can definitely work well, but other comments here mention Mainstage as the live performance software driving this decision, and offhand I can't think of a comparable app on Linux; you'd either live with different/worse UX, or have to code up something, which is not really in the scope of the quoted budgets.
I’m guessing they want orchestra sounds, and not just analog/subtractive, FM or other digital synth sounds.
With consumer and professional software, it’s never as simple as switching to Windows or Linux to get the job done when your entire back catalog of work and the training for the entire team is invested in a specific software package.
It is true that if you're (still) using PCI devices, drivers can be an issue, but there are several high end companies, including RME, with PCI device support on Linux.
Ardour, Mixbus, Bitwig and Reaper all run natively on Linux. Yes, that's a tiny subset of those available on proprietary platforms.
"Popular VSTs" feels like a wierd thing to say. I would doubt there is enough overlap in people's plugin use to every really create particularly popular ones. There are thousands of plugins available on Linux, both libre, gratis and proprietary. And even if I do not recommend the approach, many (not all) Windows VST plugins can be used on Linux. Yes, you cannot use plugins from companies that choose not support Linux without some hurdle hopping, and yes, that means that "well known" and not-easily replaceable plugins like those from Izotope and Native Instruments are generally out of reach.
The bigger point isn't that audio production isn't possible on Linux, it's that you have to make significant compromises to make it work. I count switching DAW as a significant compromise.
The cost difference between a Mac mini and Linux hardware of similar performance isn't worth those compromises to many creatives, outside of CG
That's why Ardour runs on more platforms that any other DAW, so you don't have to make that compromise :)
Apple have put quite a bit of effort into making their audio sub-systems both performant and reliable. Something that isn’t true on Windows and Linux at the moment.
I also assume that part of if is driven by audio professionals using Macs elsewhere, and you don’t want to be using an unfamiliar system when running a live performance. That’s the one place where “just let me Google that” doesn’t fly.
Your understanding is wrong, at least with respect to Linux (which technically has lower latency than macOS/OSX has ever had).
One can debate the ease of use (and to be fair, macOS will likely win), but from a technical perspective, if you want the absolute lowest latency, Linux is the system to use.
At least ... that was true for PCI audio devices. At ardour.org we've been playing around with an M1 mini, and the ease with which it gets to 16 sample buffer size with a stock USB audio device is astounding and envy-inducing.
What is the complexity with sample libraries? Until now I thought they were just big collections of categorised MP3s, and surely Mac Minis can handle those. I guess I'm missing something.
Think being able to create new virtual backup singers who you can play like a piano, pretty much on a whim, who sound convincing to the kinds of people who work production on broadway.
To be fair most sample-based instruments are not so data-heavy, but the very best-sounding high-quality ones are. They usually include some degree of software processing to dynamically alter the sound to make it sound as realistic or organic (or whatever) as possible. That's before any post-processing effects are layered on, per-instrument.
But M1 designs that max out at 16GB don't have the memory to handle plenty of sample libraries, so I don't understand how a Mac Mini is supposed to be up to the job.
It's not just about raw cycles but about cached access to the samples. The biggest libraries can run up to 1TB and you'll probably have more than one. Obviously you don't keep everything in RAM at the same time, but even so - 16GB is a serious limitation for this kind of work.
And if you're using a computer instead of a synth rig you cannot afford to have problems, because any stuttering or glitching is painfully obvious and distracting in a live setting.
It also makes no business sense for a Broadway show that may be grossing $25m a year with a multi-year run to cut costs to the bone on its musical hardware. Considering the cost saving involved in replacing real players (for better or worse...) it makes far more sense to spend twice as much initially for a no-risk professional setup than to pinch pennies and risk glitches.
Memory does pose a bottleneck for huge arrangements in the studio, but in the live setting you literally don't have enough performers at the keys for the same constraint to apply. The stuff they might trigger can be bounced out into multisamples, so the remaining bottleneck is with effects processing.
Also, if you need to replace or duplicate a unit with an identical one, you know you can always run out and easily find replacement Mac Minis. If you used some random ultra-SFF PC, can you be sure you can get another identical one easily if you need to? What about 3 years from now? Changing out hardware always introduces a possibility that something might go wrong - exactly what you don't want on a broadway show, a few hours before a performance!
The new Apple Silicon chips might be a lot faster. But I am pretty sure that audio plugins take a long time to update.
I develop on a VERY old machine in order to support backward compatibility way way farther back than Apple will allow: my current plugins will run on PPC machines because those can be used as music DAWs. As such, the machine I'm compiling on is not producing 64-bit AUs that will work, directly, on MI Macs. They work on literally everything up to that point, but Apple finally shanked me, at least w.r.t that compile target. Until then I was able to support PPC to present day with one three-target fat binary :)
Another dev, Sean Costello, told me that older builds of his stuff (pre-2017?) weren't running on M1, but everything built past a certain point (a new version of XCode, that had long abandoned things like PPC and possibly 32-bit support) was automatically working on M1 through the Rosetta layer.
So, depending on the build environment, Apple arranged that the audio plugins don't even have to be updated. Depending on the libraries the plugins rely on (a vulnerability for some of the big names that use bespoke but OLD libraries to do things), some of the plugins might need only a recompile to be native to M1 architecture. And some might be really intractable.
Plugin makers, DAW makers all refused to go down that path, despite the possibility of liberating their highly complex, deeply technical products from the whims of Redmond and Cupertino.
At that time, Linux already had better latency than OS X or Windows. It would have provided access to faster, bigger systems than anything you could run OS X or Windows on, and access to ARM "early" too. The industry could have actually convinced people that they need specialized computers, not off-the-shelf laptops and desktops to do this stuff (still largely true). But more or less nobody wanted to play.
And now, in 2020/2021, just as when the PPC->Intel shift happened under Jobs, because Apple tells them all to dance, they will.
It's sort of pathetic, even if all "understandable" from various points of view.
The situation on Linux is not "not good". Most people who comment on it simply don't know what they are talking about.
It is fair to say that Macs are easier to get good results with.
While I don't doubt that Linux can be great for audio, if the configuration befuddled someone with a CS degree so badly, I think most ordinary musicians don't stand a chance.
N.B. Compare to something like Soundflower on Mac at that time, and it's no contest -- almost foolproof to set up.
I know dozens of people who've had experiences isomorphic to yours on OS X/macOS, so the truthfulness of this anecdote isn't particularly useful in establishing anything.
But yes, as a casual user who doesn't understand or want to understand the design decisions that led to the current state of audio on a typical Linux machine, macOS will provide a much smoother experience.
I wrote JACK. I know the guys who wrote SoundFlower. I asked them why they wrote SoundFlower when JACK already existed. They said it was because 90% of their user base never wanted 90% of what JACK made possible, so they cooked up a really simple version. "But it barely does anything!" I insisted, grumpily. "Precisely", they said.
If you don't understand the engineering mindset that says that you probably shouldn't do this, then certainly, macOS will look like a much better idea (along with SoundFlower).
That will likely remain true until you run into a situation involving one of the many things that JACK makes possible (note however that I generally advise most new/casual users against using JACK these days, not because it is broken but because as your comment demonstrates, it doesn't make sense to the mindset/workflow that they bring to the table).
Seriously, that drove me away from Linux last time. When basic stuff like that just won't work, there's a real problem.
On Windows or macOS a dictatorship constrain the Audio API to be X and the Graphics API to be Y. On Linux, as a user I can choose ALSA, JACK, PulseAudio and while I'm sure there is a better option, why is the user asked to make this choice in the first place? Just choose "the best" for the user.
So Linux software usually doesn't hide stuff to users (liberty?) and this quickly translate to a worse beginner/intermediate experience, having too many choices in audio software is usually something to combat.
And Ardour is the perfect example of this: upon opening it asks several questions to the user in a pop-up, while virtually all other DAWs will reopen the last session. There is a significant divide in terms of UX, and I see a bit of this everywhere I go when booting under Linux.
There is no way for a DAW to choose "what is best" for the user. On Windows the same range of choices exists whether or not any particular DAW offers it to them. ASIO? WASAPI? WaveRT? MME? There's a case to be made for each, depending on circumstances. Only macOS really gets this right. The user can also select "auto-start" for the audio/MIDI I/O backend, which will cause them to no longer be asked which to use each time. This is a reasonable choice if they always use the same computer with the same audio interface. It's not so great if those things change quite a bit.
You're absolutely right that the GUI situation is a mess though. There is no standard graphics API on Linux beside X Window, which is totally unsuitable for direct use in any modern development effort. The desktop toolkits (Qt and GTK etc.) are unsuitable because they cannot be easily statically linked into your plugin, which can then lead to version clashes with whatever the host might use (e.g. your plugin uses QtN, the host uses QtM). There is no good solution to this: we always advise plugin authors to avoid desktop toolkits, and if possible use small standalone statically-linkable GUI toolkits designed for the purpose (PUGL, RobTk and a few others). Alas, even JUCE by default tries to link in some version of Qt (it can be turned off, and should be).
On restarting Ardour, it gives the user the choice of a new session or selecting from a list of recent sessions. I've never heard of anyone suggesting that the correct behavior is "open the last session" and this would differ from the behavior of numerous other creatives applications too. If you start up Inkscape or GIMP (or its derivatives) they will not open the most recent file/project automatically.
> having too many choices in audio software is usually something to combat.
Be sure you let the Reaper devs know this :))
This sort of pattern is conceptualized well in the book "About Face". I think it's a helpful book that explain a lot of the DAW popularity variation.
It's a bit surprising that each show in the same theatre buys their own audio equipment.
I spent a week hanging out at Circuit of the Americas helping to run a solar car race, and asked about all the loose CAT6 bursting out of every wire conduit. The broadcasters run new cable for their equipment every Formula One race, hardwire it, then cut it loose and pack up. It's apparently cheaper to do that than to debug connection problems with existing cables, or risk losing a camera feed unexpectedly due to intermittent connections from failing connectors.
Nope. Venues and especially the people who rent them can't be trusted with cabling. We now run our own every year, in an efficient combination of above ground and through the wiring troughs. We pull it out when we're done though. Only a couple things -the main internet feed, which is more robust, and the line that crosses halls- stay there to be reused (or fixed if necessary, groan).
No one likes being stuck with the landlord's choices. A designer would have worked on shows like that (work with what the venue has) earlier in his career, but not after graduation to the big leagues.
I've read claims that rosetta 2 is fast. I haven't seen results about m1 running x86_64 through rosetta vs intel though.
(M1 fan actually turned on, which is a rare occurrence; at the same time MacBook Pro 16 Intel would be frying my laps. Ballpark estimates on the internet seem to pin it down beating MBP16 6-core i7 and trailing MBP16 8-core i9 on pure CPU performance benchmarks, power obviously much lower; GPU far better than Intel UHD 630 and close but not quite as good as Radeon 5300M.)
For most applications that aren't especially pathological for Rosetta (e.g. V8 x64), it seems not more than 10-30% slower than arm64.
(Don't feel too surprised. If your binary is static code, it is pretty much a static compiler from x86 to ARM [albeit an incredibly well executed one], so not magic: in fact if you disable SIP on your system, you can peek into the translated executables in `/var` and look into them via `objdump`/`otool`)
--
Another benchmark that is a bit worse for Rosetta:
Compiling gRPC from clean source (not quite Apple to Apple comparison cause under Rosetta, it runs LLVM x86 codegen vs LLVM arm64 codegen outside Rosetta and I did not want to mess with the flags). I also feel like process creation under Rosetta can be more expensive, but not sure.
- MacBook 16 (i7-9750H, 16GB): 67s
- MacBook 13 (M1, 8GB): 48s
- MacBook 13 (M1, 8GB, Rosetta): 85s
Now I have my Intel Macs to list on Craiglist...
The cynic in me says the sound budget will get cut further.
is it because of the synthesizer software makers write very bad code,etc ?
i would have thought that a modern iphone 12 pro would be sufficient to run synthesizer libraries
> Mac Minis
> Apple Silicon changes everything for Broadway electronic music designers. The new M1 Mac mini is capable of running high-end sample libraries and virtual instruments in a stable manner, and it’s only going to get better with M2, M3, and M4-series chips in the future. The performance per dollar characteristics of Apple Silicon machines are going to have a huge impact on Broadway’s sound, and I’m very excited to see, or hear, what happens.
What will happen is probably that your budget will get reduced, since you don't need as much to deliver the same quality as today.
This is to suggest that Broadway shows could already have achieved the same increase-in-sound-quality-per-dollar by switching to cheaper hardware running Windows, and that the M1 introduction isn't really the big sea change the author makes it out to be.
CoreAudio is native to macOS/iOS and very stable. The latency is low and most of the time you don't need to install anything: just plug an USB. It even provides APIs for running the plugins, if the DAW wants to use AU. Hell, even the built-in interfaces has good latency on Macs. Also, if you have multiple, different branded interfaces, Apple provides a tool to "merge them" so your DAW pretends it's only one.
On Windows you need an alternative third-party driver solution, ASIO, just to get proper latency. Microsoft tried DirectAudio, Kernel Audio, among other tech, but it never worked and/or never caught on. Even ASIO is not as stable as CoreAudio and requires installing (sometimes unstable) third-party driver software and control panels. IME, sometimes those drivers conflict with each other, so you can't use multiple soundcards at the same time, or swap them. Most people eventually get there, but it still feels like a house of cards.
There's a lot of small studios that choose Hackintoshes, so it's not really the hardware, although M1 might change that, who knows.
I think you're right that legacy, mindshare/knowledge etc played a big part in it, and I'm sure Windows is much better with this stuff now. Although the handful of studios I've been to in the last few years were still running Macs, but again maybe that's just mindshare.
A funny thing I realized recently while trying to setup OBS for video conferencing on my Mac at home (I work as a teacher occasionally): There is no way out of the box to capture system audio, you either need to do it through external hardware or use a hacky solution like Loopback. On Windows, this "just works".
In other words, you and OP may both be right. Three absolutely massive transitions at apple between your era and theirs: hardware, software and management quality.
Your bad luck was that you bailed out of the MacOS audio subsystems just when they started to get good.
Any user who needs to perform audio with any computer will need a soundcard in order to have any sort of decent quality, for #1 Decent quality inputs and outputs #2 The correct input and output types like XLR (or fibre optic or whatever) #3 Acceptable latency for live performance.
Soundcards are available for mac or windows, the makers provide drivers which deal with the "Audio and MIDI stacks". From a users perspective theyre both fine. After that, you care about the machines performance, CPU, how much RAM, how fast is the RAM, how fast is the SSD.
MS tried a bunch of tech in the past (WinMM, MCIWnd, DirectSound, WaveOut, WASAPI, XAudio2, etc), but none of them ever worked for professional Audio.
The proper solution was always to use ASIO, which is third-party technology by Steinberg. It works but it's not integrated with Windows: it goes directly to the audio interface, bypassing stuff in the Kernel.
This bypass causes some limitations, such as not being able to use the system mixer (which prevents from using media players or multiple audio apps), or sometimes having different audio-interfaces not work well with each other.
There are workarounds to those issues, but they have to be handled by the interface manufacturer when writing the drivers. Also, you can't have low-latency with built-in soundcard unless you use something like ASIO4ALL, which is not super stable IME. This sucks when you want to work on-the-go with headphones.
Of course, it can be very stable when you use the right combination of DAW, drivers and sound interfaces, but when you don't you have problems.
On macOS and iOS? CoreAudio is native and it has super low latency by default. It's mostly plug and play and all apps use it. It even provides APIs to use Audio Plugins or reroute Audio, so DAW writers don't even have to write it themselves (unless they want to). Do you have multiple Audio/MIDI interface? In macOS there's a built-in app to "link" them together.
Mac Minis are relatively cheap. Not much different in cost to comparable, branded, ultra-small-form-factor PC hardware. (And now, with the M1, I don't think you'll find competitive PC hardware in the same price range and form factor at all)
I agree that it is at least super competitive on pricing with comparable compact HP/Dell/Lenovo 8-core desktops. This was surely not true before M1 (I'd say on the order of 2x improvement in mini price-performance).
I suspect this will remain true for a at least a little bit more since Ryzen 5xxx are beasts too, and once supply-demand gets more balanced, machine prices will likely come down at or slightly below Mac mini M1.
On the laptop side, however, M1 is glorious and way cheaper than performance-matching alternatives.
[1] https://www.officedepot.com/a/products/7814504/HP-Pavilion-T...
But having run music on Windows for a long time, I would never ever go back. The telemetry, random updates, and general awfulness of the user experience are not something I want in my life.
MacOS has issues, not least the breaking changes in Catalina and Big Sur. But when each OS iteration settles down it's generally super-stable and - most importantly for professional use - it doesn't get in the way.
Indeed, the whole point of Apple buying Logic (and discontinuing the Windows releases) was that they needed a DAW on MacOS to get audio professionals to consider the OS. People don't remember this any more, but the Apple versions of Logic were very much inferior to the Windows versions.
I hate to be that guy, but your entire comment is full of wrong.
Firstly, Emagic "Logic" started on the Atari and Mac OS platforms. I'm not sure when it appeared on Windows, but it certainly wasn't a Windows first DAW. The Apple versions of Logic were never "very much inferior" to the Windows versions. In fact, it was the other way around.
> Indeed, the whole point of Apple buying Logic (and discontinuing the Windows releases) was that they needed a DAW on MacOS to get audio professionals to consider the OS.
The fact of the matter is, practically all "audio professionals" of the time period of which you refer, used Apple computers - either for MIDI sequencing, or Digital Audio Workstations. Windows computers weren't even a serious consideration. Those who didn't, still used Ataris, or hardware sequencers/recorders.
Pro Tools, originally by Digidesign, was Mac only for years also.
Today, most Hollywood composers use Cubase, which was definitely Windows-first. TV productions favor Studio One, which again, was Windows-first (and from the same developers as Cubase). Pro Tools is industry standard for Hollywood movies...but it didn't become the standard until version 6, running on Windows. Ableton Live, which is the most popular tool for recording live music, was written first on Windows (but originally commercially released simultaneously for Windows and Apple).
And Logic on Mac was very much inferior to Logic on Windows, which is why Windows was the preferred platform for running Logic. The Mac version didn't become better than the Windows version until version 6, for which there was no Windows version. While all accounts say that Logic is a great DAW these days, because it's Mac-only, the only production companies that run Logic are ones that are exclusively Mac-based.
I want to be charitable, and hope you're getting confused about the "Apple" versions - in that, you're conflating when Apple (the company) bought Emagic Logic, for when Logic (the software) was available on Apple Mac OS?! Either way, doesn't make your former statements any less incorrect.
The Atari ST Cubase 1.0 would like to dispute this. I remember sulking because it wasn't available for my Amiga.
Windows version didn't come until 1992, the Atari and Mac versions were released before that (Mac before Atari, however, the precursor by the same company was developed for Atari first).
Logic Pro is, of course, Mac-only as it's made by Apple.
We're not talking about an organization moving to Windows here, we're just talking about a single, appliance-like keyboard-input-to-audio-output computer for someone to play music on in a live Broadway show. TFA writes about buying the machine new for that single purpose. There aren't really "switching costs" in the traditional sense in that circumstance.
TBH I think it's just an ad. The circumstance (we have to buy two brand new computers for every run of a show!) and claimed impact are just too contrived.
EDIT: Further supporting the idea that it's just an ad, every other post from this domain on HN is promoting a product.
1. We use Macs because we need MainStage for these shows. 2. Mac mini fits the form factor. 3. Faster Mac mini means we can do cooler stuff.
Easy.
Anecdotal: I sold my 2011 MBP to a musician. Best machine I ever owned, but will never buy another Mac.