Hacker News new | ask | show | jobs
by duped 412 days ago
I don't disagree with you, but there simply isn't an alternative for pro audio developers. You go where the users are and the majority of the market (by revenue) are Mac users.

Now a lot of people may reply to this that Windows isn't that bad with ASIO (third party driver framework) or modern APIs like WASAPI (which is still lacking), or how pipewire is changing things on Linux so you don't need jack anymore (but god forbid, you want to write pipewire native software in a language besides C, since the only documented API are macros). Despite these changes you have to go where the revenue is, which is on MacOS.

9 comments

> I don't disagree with you, but there simply isn't an alternative for pro audio developers

People used to say this about video pros too, until Apple royally screwed the pooch by failing to refresh its stale Mac Pro hardware lineup for many years, followed by a lackluster Final Cut release. An entire industry suddenly realized Windows was viable after all, they just hadn't bothered to look.

But they had to be pushed in that direction. IT actually affected their work.

In this case, the users of these tools seem perfectly ok with them and aren't going to just explore something as disruptive as an entirely different OS just for kicks.

Not sure why you started off with "but" when we are in agreement and/or you're not disputing my point - that Windows is viable but the Mac-using audio professional aren't (yet) sufficiently motivated to seriously evaluate Windows as a migration target.

> In this case, the users of these tools seem perfectly ok with them

That wasn't my takeaway from the article. The plugin is outright broken on the latest hardware, even with the workaround.

> [...]something as disruptive as an entirely different OS just for kicks

I don't think switching OSes is less disruptive than switching software packages. Cubase or Ableton on Windows is not much different from the respective DAWs on Mac OS. Modern desktop OS UI paradigms map 1:1, so switching isn't a big deal

That comment was left in haste, sorry. To clarify, I meant that in the case of FCP and movie editing software, they were almost forced to switch.

The FCP upgrade didn’t just break the main app, but the plugin ecosystem was wiped out too. (From what I read, I’m not a movie pro). And that was disruption forced upon the users.

So in that scenario, they didn’t have much of a choice.

But in this scenario, the audio apps work well and it’s just the developers complaining.

And even though I’m a developer, I would say as long as the users are happy then I can see why there is less concern about dev happiness

> You go where the users are and the majority of the market (by revenue) are Mac users.

One of the worst things about Apple is how much time and effort they spend trying to lock you into their platform if you want to support it. There's no excuse for it. Even once they have you on their system, they're doing everything in their power to lock you in to their workflows and development environments. It's actually insane how shamelessly hostile OSX is.

This is "don't anthropomorphize the lawnmower" territory imo. I don't think Apple is actively hostile to 3P developers or tries to lock them in. I think they simply don't care - or lack the institutional capacity to care even if individual developers in the organization want to care.

The Apple developer experience is an abject horror because they believe everyone who is capable of developing high value applications for Apple devices works at Apple, or will work at Apple. 3P devs are a nuisance they tolerate rather than a core value-add for their services and devices. I assume it's less bad within Apple, but I really have no idea.

I'd argue you can see the hostility if you compare shipping to Windows vs shipping to Apple. Microsoft doesn't care if you copy over your MSVC suite into a Wine environment to build your software for their platform. Even SignTool just works. It's not necessarily trivial to do, but that's simply because the MSVC suite is a horrible mess like everything else Microsoft.

Apple explicitly disallows cross compilation in their Terms of Service. Even if you managed to get clang compiling for Mac on another Unix, even if you figure out how to get your app bundles signed outside of OSX, they'll revoke your developer license and invalidate your certs because you're in violation of their ToS. You're right they don't care about third party devs, but the amount of hoops you have to jump through for devops on Mac is almost certainly designed as a gluetrap.

Agreed.

I think Apple is actually one of the few companies that you should anthropomorphize because they have shown a long history of making decisions based on long term strategy rather than short term profits. They also react emotionally sometimes. Best example coming to mind is Steve Jobs on Accessibilty, "I don't care about the bloody ROI." I of course cheered that attitude, and still do for a11y, but that is a very human-like thing to do. Also lets not forget his hatred toward Android and vengeful attempt to kill it. Hence I don't think Apple is a lawnmower. They're more like an elephant with it's objectives and they know they're going to squash a lot of lesser life in the process but "you can't have an omellette without breaking a few eggs."

(From private conversations with people at large tech corporations, my understanding is that that provision of the ToS is inconsistently enforced. Obviously not a good place to be for independent developers, since it partly depends on if you're important enough.)
> I'd argue you can see the hostility if you compare shipping to Windows vs shipping to Apple.

Windows has had 3rd party developers built into its DNA since the beginning though. Even today, Windows goes to great lengths to maintain backwards compatibility. I think this comes from the fact that MS has always been a software first company built around market domination.

Apple is mainly a hardware company it is saying you must buy our hardware if you want to make money out of our users.

That is not being developer hostile. Apple does many other things that don't help developers but forcing their hardware is just an entry cost.

I don't even understand why they are following a cash cow strategy of milking their current customer base dry when they could be growing massively.

They have amazing hardware that is far superior to the competition and that they can build at very competitive prices while still making good money.

Building a PC in 2025 absolutely sucks. The prices are getting insane. Plus Windows 11 is super hated. It is the perfect time for Apple to win over people.

They just need to stop kneecaping their great hardware but the shitty software side. Just open it up a little bit. Add Vulkan support. Actually make your GPU usable. Actually help Steam to do their magic like they did with Linux, no one is going to buy games on the bloody Apple store anywhere. Show some respect to the developers.

Shareholders giving up massive growth for short term profits. So frustrating.

Exactly what are they suppose to do if not create their own frameworks to bear leverage their own hardware? Do you want them to use cross platform frameworks that are not optimized for their system?
My problems start long before the special APIs come into play. When we supported Mac, I just wrapped the APIs like you do for any other system. The problem is I don't use Mac, so building software for Macs is inherently troublesome. I can build and test for Windows just fine from Linux and OpenBSD. I can't for Mac.

Now you might say this is problematic, Apple doesn't want third-party developers locking their platform behind some conditionally compiled set of abstractions that ruin everything they've worked for. Putting aside how ridiculous that is given system APIs are often wrapped for normal abstraction reasons anyways, that's totally fine. But then, it's also not my problem because I'm not Apple. I don't mind supporting their platform, I'll even turn a blind eye to the audacity of charging a developer fee while offering abysmal documentation and support. But I'm not going to crawl and beg for the privilege.

> Do you want them to use cross platform frameworks that are not optimized for their system?

Just like everybody else, because it hardly matters. Outside of Apple-land, Intel, AMD and Nvidia all get along just fine with rewriting SPIR-V to their microarchitectures. CPUs get along just fine rewriting abstract instruction sets like AMD64 and the various ARMs to their microarchitectures. Code is by-default compiled for instruction compatibility. APIs like CUDA and ROCm explicitly exist for vendor lock-in reasons. There's absolutely no reason why the throughput of these APIs can't be generically applied to compute shaders. None at all. The hardware vendors just want to capture the market.

Apple isn't exactly working with exotic hardware. The M1 is yet another ARM chip, not some crazy graph-reduction machine. These standards are fine and used across a wide-derth of hardware to no real detriment. I would suggest you may over-estimate how much they actually care about this idea of "specially optimized APIs." Consider that Apple pushes Swift as the primary language you Should be Using to ship software on OSX, and yet garbage collection is still handled in software. That's not what vertical integration for engineering purposes looks like.

Again, it all hardly matters. I wouldn't mind just wrapping these APIs, they're not particularly special or exotic any more than their hardware is. But the fact of the matter is that as a non-mac user, they go through a lot of effort to ensure putting software on their platform is as unattractive as possible.

The way I see it, they mainly just aren’t interested in devs treating macOS as just another lowest-common-denominator target, which makes some amount of sense. Such software is likely to not be as nice to use as something purpose-built for the OS, particularly when considering that the dev probably never even tested the software in question under macOS, greatly hampering their ability to find and eliminate bugs.
Why would I want to use software that you never tested on the target machine?
I explicitly conflated building with testing not even 4 sentences into my post.
Because it's not 1982 anymore?
I didn’t buy a Mac to use your lowest common denominator untested, unoptimized application that doesn’t take advantage of my hardware to its fullest.
What I always find curious is how some of the biggest Apple supports are likely some of the same folks who were super anti-MS in the 90s.
Eh, is this worse than Windows? You develop UWP or WPF or whatever the current flavor is with Visual Studio, and use C# APIs that only exist on their platform.

On Mac, I can use bash/zsh mostly how I would on linux. The main compatibility issues come from BSD tools vs GNU, which are very simple to replace if you want. On Windows, they use PowerShell, which is totally proprietary.

On Mac, web & infra development can use completely open source tooling which can be shared with Linux.

You can still use VS Code to edit Swift (or C#), but the more "proprietary dev environments" (Xcode or Visual Studio) are probably more powerful with system level integrations.

Heck, you can use PyQT on mac if you don't like Swift or Xcode.

There is an excuse: shareholders. The more lock in there is, the more the champagne flows.
Trillion dollar market caps don't come for free. The Apple Tree must be watered with the blood of third party developers so our gracious overlords can Do Computing Different.
You can’t imagine how often I pine for x86 based Windows laptops with horrible battery life, loud fans, and enough heat that if I work with my laptop on my lap for an extended period of time there will be no future Scarface’s. But I’m locked into my Mac because of the dirth of Windows software.

Not to mention all of the great Android tablets that I can’t get or the much faster Android devices…

This would be a more poignant point if you had to sacrifice any of these things to get better developer experience. But you don't, you're intentionally conflating wildly different things to defend an irrational stance.
If my developer experience depended on me using an x86 machine, I would have to sacrifice all of these things
How is WASAPI lacking? I thought the abundance of FL Studio beat producers proved that for audio work, today, Windows is completely fine.
Basically every software (except Logic) is available on Windows but users still buy Macs. Even among those users, people usually fallback to ASIO instead of directsound or wasapi backends.

WASAPI requires exclusive mode to be useable for pro applications, or else your latency will suffer and they may be doing some resampling behind the scenes.

Exclusive mode is a feature, not a bug. If the user needs the bits coming out of the user's DAW to reach the speakers as pristine as possible, then the user probably doesn't want these bits mixed with any other application. If the user needs to switch between the DAW and a Youtube tutorial, then there's probably no need for exclusive mode.

Latency is a valid concern, but is it really bad? PCs are fast now.

afaik it's not possible to configure buffer size and sample rate from within a user application without exclusive mode, which actually does matter for the non-exclusive use case. iirc it was even worse where applications' streams would be resampled transparently and buffered, which is absolutely not what you want.

I don't use windows for audio anymore so I can't comment on this in win11, but it used to be that WASAPI suffered unless you set your PC in "performance" mode in your power settings whereas ASIO was unaffected.

And yes, latency matters! For live performance you're looking for < 2.5ms of one-way latency to get a roundtrip of under 5ms. After that point it starts being perceptible to players. This is not a performance floor so much as a scheduling one, and ime windows audio scheduling under dsound/wasapi was always shakey.

I see. Thank you!
For a DAW running in exclusive mode, wouldn't they also have the option of setting the system default output to a virtual device that inputs into the DAW? That seems to me like it would be the most sensible way to handle mixing in YouTube or whatever.
Agreed, you're in probably the toughtest spot.

That said, Reaper and many others have done great things with DAWs and other audio processing in C++. Maybe getting a "native" look is too difficult, but I figured I'd throw it out there.

The problem is not the application software but the operating system and hardware. Linux is arcane and Windows is permanently behind the curve.
There is no buts. If you make a decision that you are going to live with a framework that is hostile to your efforts, then that is really your choice to make your life harder. If you really want to make things better for pro audio devs stop enabling organizations that want to mold you into there way of looking at the world. Blog about it and let the industry know you will not tolerate non-freedom in software. The same goes for windows people. Move away from non-open source, take back control of your life and find other endeavors that support open source until the idiots get the point. Stop enabling your jailers.
> (but god forbid, you want to write pipewire native software in a language besides C, since the only documented API are macros)

I've read that Zig can wrap C macros. So maybe there is some hope.

> You go where the users are and the majority of the market (by revenue) are Mac users.

You go to a different market.

FWIW I have worked on several professional live audio productions and never heard of Anukari once. This is a pretty niche domain regardless of what circles you work in. It's really not about "X job is for Y OS" here.

> there simply isn't an alternative for pro audio developers.

Tell me you don't work on live audio without telling me you don't work on live audio. Windows has always been usable if you have a suitable ASIO (same as you used to use on Mac). Most shows will use some permutation of Windows boxen to handle lighting, visuals rendering, compositing and audio processing. The ratio of Macs to Windows machines is at least 1:10 in my experience.

Heck, nowadays even Linux is viable if you're brave enough. Pipewire has all the same features Coreaudio was lauded for back in the day, in theory you can use it to replace just about anything that isn't conjoined at the waist with AU plugins. Things are very different from how they were in 2012.

> Tell me you don't work on live audio without telling me you don't work on live audio.

This is pretty rude, I'm among the (probably small) subset of HN users who has developed real professional audio software.

All I can talk about is my experience, which is that in the plugin market a plurality of your revenue will be from MacOS users. My last job in this market had zero Windows/Linux users.

Now I have done a good bit of live work on Windows machines with ASIO, but I also do a bit of work there myself from time to time in venues with musicians - and I don't really know any musicians that are carrying around Windows laptops. 100% of them are using Mainstage and Ableton on Macbooks.

> Windows has always been usable if you have a suitable ASIO

The gold standard being RME hardware and drivers. Not a single issue ever on windows.

They sell hardware, that shows demos well. They cannot do a demo at MacWorld because it does not exist anymore and worse, they don't care. I would suggest a jack black/school of rock appeal, but you are speaking to a company that is literally tone deaf to everything but what sells product.

There is no revenue in MacOS, there is only revenue in machines that run A free OS, that they consistently lock their loyal customers out of.