No idea but it apparently has motors. Firmware should protect against damage this way but perhaps they didn’t account for the way Big Sur would end up communicating with it.
The device that can be damaged is a DJ controller with haptic feedback. So it has motors in it, and some kind of audio outputs. If the audio levels get turned to maximum or the motors get sent invalid commands, it could cause the device to damage itself. I’d call it a firmware problem if the motors can be commanded to move too fast, but anyway it may be reason for them to warn their customers. The editorialized hacker news headline makes it look like Big Sur is to blame, but it could easily be written as “Native Instruments Hardware does not fully support Big Sur and could be damaged if run on Big Sur.”
Yeah, that is an issue of the device IMO. It should prevent itself from being run in a destructive manner so long as the bus itself is in spec (ie no overvoltage, reverse polarity, etc). Unless it is clearly labelled as not to be connected to any system that hasn't been specifically evaluated and qualified by them, this shouldn't be the customers fault.
Also, I initially misread this as National Instruments and imagined a DJ programming in LabView, LMAO.
It's definitely a buggy device/firmware. There is no way an OS update can cause this (barring some massive Apple bug which is unlikely); more likely the device firmware mishandles some valid standard USB commands that older OSes didn't issue.
In general, it's quite common for USB device firmware to be of extremely poor quality; it'll be tested and bugs fixed until it works with the target OSes and drivers, but no comprehensive testing of whether it can deal with all possible standard request patterns is done.
As I understand it the Kontrol S4 has moving parts (essentially motors) under USB control.
Obviously you could design this sensibly so that no legal inputs result in malfunction let alone damage, but that might cost more, so, do it all in software right? And then you're at the mercy of the software and anything (such as the OS kernel) which that software depends on.
We do teach Computer Science / Software Engineering students not to do this, showing them e.g. the Therac-25 incident as an example of why software control isn't enough - but well, check out how many HN regulars are proud that they either didn't pay any attention in class or never attended and are "self-taught".
SANE (the Free Software document scanner software) has run into cases where it's just cheaper to have code that checks "Is this the end of the bed? If so, turn off the motor" than spend five cents on a limit switch or one cent adding a stop so that the scan head physically can't fall off. Somebody reverse engineering a driver sends "Move scan head" and, to their astonishment, it falls off its rail and their scanner is broken. Oops. Now, who feels comfortable shipping that to users knowing if your finished driver didn't catch every edge case you might destroy their scanner?
IIUC, that example seems more like an indictment of the scanner manufacturers, not the developers of SANE. SANE includes that code because some manufacturers didn't implement such a simple, obvious, and crucial constraint in the hardware. Unless maybe the poster's point was that the SANE developers shouldn't try to support such fundamentally broken hardware?
SANE (Scanner Access Now Easy) is named that way because it does what people on minority platforms assumed TWAIN does on Windows / MacOS.
TWAIN (sometimes said to mean "Toolkit Without An Interesting Name") looks like it's a universal API for scanners, except, the mandatory parts just spin up a graphical user interface and that does all the actual work. There is no actual scanner technology in TWAIN, each scanner comes with its own GUI plus scanner driver bolted into one app.
So in TWAIN there is no API for like "Scan A4 document, 300dpi" only "Make whatever Twain GUI I have appear" and when you buy a scanner it just comes with a CD (I guess these days they tell you to download it probably? I have not set up a new scanner in decades) with the software on it.
But SANE does what people assumed TWAIN did, the GUI application software is neutral, and the code for driving scanners has APIs for scanning documents, because that makes more sense (and also, frankly, "reverse engineering USB code" and "building easy to use GUIs" are not the same skill set). As a bonus it means you can network SANE, just by adding an RPC layer, whereas for TWAIN you'd need like RDP or something. Blergh.
> many HN regulars are proud that they either didn't pay any attention in class or never attended and are "self-taught".
It's because companies want "superstars" (ie: underpaid people with something to prove by spending a whole bunch of unpaid overtime in order to get $50k at the end of 2-3 years when the company is sold)
The truth is in the hardware game, you end up cutting corners in order to deliver something someone will buy because if you're a dollar pricier than the next guy noone will build your plastic AF product.
There are those of us who are "self-taught" who are familiar with Therac-25 and other incidents. Don't think that a college degree somehow magically infuses engineers with ethics and judgement.
That comes from a culture of engineering that focuses on learning and continuous improvement, otherwise we'd just be fixed in time the moment we left school.
I can't speak for other degrees, but mine didn't magically infuse me with ethics. It was the full credited modules solely dedicated to just ethics that aided in that department.
Ethics was an elective module in my CS degree. I took it because it seemed easier than some of the more advanced programming courses. 20 years later, I’m glad for the choice I made as a lazy youth.
In countries like Portugal, where Software Engineering is a professional title, just like in other engineering disciplines, ethics is part of universities being allowed to teach the degree and professionals being allowed to call themselves engineers.
No hardware vendor would actually design that way. Pretty sure there are some driver ICs for those motors which take care of those spikes. Besides, controlling voltage limits via software is pretty expensive to do compared to just slapping a driver IC. The problem is most likely not the motors, but something else.
A big risk with audio hardware is that buggy os drivers might lead to noise being output. One can attempt to detect and block this in hardware, but a compressed EDM track with reduced dynamics can look pretty close to loud noise at some short moments.
Now let's say you have a high power Amp configured correctly for mixing a -24db classical music recording and then the OS glitches out and you hear 0db noise. That might blow up your speakers, headphones, or even worse, your ears.
My experience writing kernel drivers for audio software is that Windows will accept the click sound and then stop processing if the buffer runs dry. OS X used to have issues that it'll continue playing, meaning it'll reinterpret random memory as sound. Not sure if that was fixed in recent Mac versions, as their approach does have memory & performance benefits. But it means that audio driver glitches on Mac can be physically painful for the user.
> Now let's say you have a high power Amp configured correctly for mixing a -24db classical music recording and then the OS glitches out and you hear 0db noise. That might blow up your speakers, headphones, or even worse, your ears.
I experienced one glitch like that while mixing with headphones, it's hard to describe how loud it was, a bang in my ears that made me fall and left me shackling for a few minutes. If you have ever be surprised by headphones at max volume, imagine it's even (way much) louder (because music at max volume is not a full 0db white noise). To this day I now avoid playing with plugins with the headphones and only put them for the final mix/mastering.
Why does Apple get the Professional OS nod when EVERY update is a break in your workflow Majorly. Heck every Mac is always on a different update because they are scared to even update in Mac only cooperate networks like mine. It has always been a pain in my video editing life too.
>Why does Apple get the Professional OS nod when EVERY update is a break in your workflow Majorly.
Because every update usually also moves things forward. E.g. on Big Sur they moved third party kernel extensions to userland ones. That's safer, less crash prone (an extension issue doesn't bring down the whole system), more modular, makes it possible to upgrade an extension without a reboot, and so on.
Check PC forums of pro music users how often they have issues with drivers, incompatibilities, updates, etc.
And that's not with "switching to a major new architecture" issue, or "moving kernel extensions to userland" type fairs, which are major changes and can understandably bring issues with them (but can be totally worth it long term).
It's just incompatibilities between the million different hardware combinations you can find in a PC, Windows issues, etc.
>Heck every Mac is always on a different update because they are scared to even update in Mac only cooperate networks like mine.
Actually it has been reported time and again that Macs are among the fastest percentage wise to move to the latest OS version compared to Windows PCs, with something like 70% having moved over in a couple of months...
>Just because something move forward doesn't means it moves in the right direction.
Sure. In this case though I meant "in the right direction" too. I, for one, welcome third party kernel extensions moving to userland.
>Do they ? How many brain-time did Apple waste yesterday by soft-bricking ALL THE DAMN MACS running Canalina ?
A little. Nothing like the brain-months I've wasted on Windows and Linux troubleshooting, and I've been using Windows for ~30 years, and Linux for ~20 (plus several UNIX varieties of yore, like SunOS, Solaris, and AIX, with the ocassional toying with FreeBSD as well).
I'm annoyed by several things in Apple land as well (e.g. the keyboards on the last 3 years on laptops, the firewall bypass situation in Big Sur, the not-so-useful touch strip, and lots of minor issues), but I'm also annoyed by the "grass is greener" sentiment all the time, or the "sky is falling/Stallman was right" rhetoric...
Maybe I am doing something wrong here, but I use Windows for 10 years, then switch Ubuntu for 5, and Mac for less than a year right now (so I am on Catalina).
I feel that I spend 2-3x times troubleshoot my mac than Ubuntu. I still haven't been able to find a cause for intermittent entire UI froze I experience 2-3 times a day.
Many forget that a large number of Mac customers are not US based. In fact, many live in areas with no apple stores at all. Seems to me that apple is glad to sell to everyone but only really care about a few.
Apple online support has probably been my worst experience ever. On something as simple a ordering 2 magsafe power supply, they manage to only send me 1, and had to wait 3 weeks without any communication to finally get the notification for the second one shipment after a support call. Every low-key chinese Ebay sellers has better support than that.
>Apple online support has probably been my worst experience ever. On something as simple a ordering 2 magsafe power supply, they manage to only send me 1, and had to wait 3 weeks without any.
Worse support experience ever, or worst experience ever?
If it was the latter, you have a pretty sweet life!
But even if it was the former, you must have had some pretty great online support experiences until that point...
Does Apple have a "Release to Manufacturing" phase in their release schedule before the product is GA? A time for all their software and hardware partners to fully vet their product against the gold master.
There have been a series of beta releases since June. (For some reason, they say in the linked page that beta releases have only been available since August, but that's not correct).
I don't maintain software, but I've heard from multiple others that since betas are just dumped and things are quietly added, changed, and removed, it's difficult to trust a beta for development.
Things aren't quietly added/removed. Each release comes with updated release notes/changelog and typically points out things that are WIP or broken temporarily.
macOS updates almost always break a lot of audio apps. You're better off waiting a few point updates and checking with the vendors of the apps you use before upgrading.
I'm still running Mojave. Fuck 'upgrading' to an operating system that kills a ton of 32-bit VST plugins I paid for a decade or so ago that will probably never get updated, while adding no meaningful features of substance for me.
I don't need a dark theme. I don't need to be able to answer calls from my iPhone on my Mac or whatever.
I just need the software I have paid for, that has worked for 7 consecutive software iterations, to continue to work.
I'm in the 'Snow Leopard was peak MacOS / OSX' camp, honestly; having used the OS as a daily driver since 10.3.x...
>I just need the software I have paid for, that has worked for 7 consecutive software iterations, to continue to work.
This contrasted with your last sentence is amusing because it can be applied to 10.5 (no more CE) 10.6 (no more PPC hardware) and 10.7 (no more Rosetta)
which begs the question... Is backward compatibility dead ?
People are rejoicing when developer updates their app "fast" to support new OS, but once upon a time, one wouldn't even expect to have to update anything at all, just because "new OS version". You can easily run Win 95 app on Win 10. I can run a CNC controller built for WinXp, controlling very destructive equipment on Win7 without issue, and I've been using statically linked binaries on Linux for years without problem, so really WTF ? Are Apple fans just that blind ?
It's just buggy, not dead. However there should be a point when backward compatibility should be dropped, if you want to keep maintaining a sane codebase and interface, or force a "better" way of doing things. When Apple deprecated OpenGL and moved to Metal, I hated it but I actually respected a lot, cuz Metal does have a superior design, and by deprecating old technology they're forcing devs to use this better technology for better software (being proprietary is separate issue).
Looking at the list of hardware that doesn’t work anymore and I’m delighted I didn’t buy any when i was considering it. I would be very pissed right now if the expensive hardware I bought stopped working due to an OS upgrade. Most of my musical equipment is much older than NI as a company even and I never have to worry about it breaking due to software updates.
> It's just buggy, not dead. However there should be a point when backward compatibility should be dropped, if you want to keep maintaining a sane codebase and interface, or force a "better" way of doing things.
Not when millions of people rely on working computers, and as much third party peripherals.
Then I'm interested to know when, what's the number of years, should we drop backwards compatibility for a certain version of interface, if ever. I'm sure there're still a lot of punch card programs and today no new system support it. Also there's always a option to not use the new technology that dropped backwards compatibility, which is why many people still buy second hand game consoles and casette players. I love them, but I accept the fact that they're no longer backward compatible with new devices.
Audio Software (and firmware) developers are really not the benchmark for this. They always lag behind, exploit hidden / unsupported features and never manage to play by the rules of the platform they are on.
All this is enabled by the music gear community which blindly accepts a 2k synth (e.g. Moog Matriarch or Novation Summit) to be riddled with bugs one year after release or companies like NI or Elektron to always be 6 months late with compatibility for new Mac OS releases (first Catalina, now Big Sur), shifting blame on Apple.
It's Apple's platform - they signal changes well in advance. As a developer you either support it and play by the rules or move off it.
NI hasn't even managed to update their UI to the high DPI / Retina world in many cases.
No offense, but why should the software developers just pour money and resources into maintaining ever changing OS requirements and hop through Apple loops for no visible customer benefit (e.g., better and additional capabilities)?
Why do software developers have to spend money because Apple keeps changing the stuff constantly?
UX retina are non-trivial changes. In the case of Qt, I recall that this meant changing the version this dropping other OS versions that were previously supported unless you duplicate all development effort.
Apple has NO incentive to not keep changing everything and breaking stuff thus forcing people to constantly upgrade and buy new hardware. For me, there weren’t any material changes in the OS I was happy and started using.
What this shows you is that it has become financially unviable for pro audio companies to support Apple.
[1] is practically the same announcement by Avid Pro Tools, which is the standard for Hollywood movie production.
I also have a personal stake in this, because I used to sell pro audio software, including things that integrate with Pro Tools and OS X. We saw the writing on the wall around OS X 10.11 when major studios asked us to support Linux and subsequently bought $40k Linux-based mixing desks.
The fact is that any professional customer that uses NI has jumped ship years ago, so for Native Instruments the Mac market is shrinking in revenue, while growing in costs.
In my case, Windows and Linux are now paying for feature development. We still snort out OSX binaries from an old 10.9 xcode, but those aren't notarized because no paying customer has asked for it yet.
This is what happens if you don't value the time of your third party developers, for example with useless updates and poor documentation. I'm sure Apple will spin this as "the app store provides", but there's only so much work you can put in for a platform with a median lifetime app revenue of <$1000.
In short, professional movie studios have voted with their money, and now the market follows suit by canceling Mac support.
Thanks for valuable information. I am planning to make a little home studio for me and my friends, would you be so kind to give me advice in which DAW to invest my time, and what are alternatives on linux regarding support of thunderbolt or usb interfaces. Is windows the only future-proof and viable option for producing music nowadays? Thanks in advance.
My impression is that most Hollywood work is now done with Pro Tools on Windows. For example, I know for sure that Expendables 3 was mastered this way.
For classical music and bluray mastering, I hear the most from Nuendo users on Windows. Their cheaper variant Cubase is popular for audiobook production.
For music production, BitWig and REAPER are currently the rising stars. Both are popular on Linux:
BitWig especially fits in with the hacker spirit because you can modify and script almost everything.
They also have many features for live shows and / or DJing. That market used to be squarely owned by Ableton on Mac, but the latter has recently fallen out of favor over plugin compatibility issues with newer effect VSTs.
For broadcast, meaning TV shows and live sports streaming, I heard that BBC and the likes are using LAWO which are custom integrated hardware+software solutions capable of loading Linux VST plugins.
I make music, and I have to say, the jump to 64 bit and the jump to macOS 11 have been pretty damaging to my workflow in the short term. My DAW, my drivers, and my plugins are all written by different developers and they all need to update for me to get fully back to work (In fairness, I made the mistake of upgrading eagerly to macOS 11, which is on me).
At the same time, working on a Mac in general has been so, so much more reliable than working on windows. I used to have endless problems with dropouts or latency problems on windows, regardless of the driver, sound card, or buffer size I used. I’m sure things have improved in the time since, but I’ve been so much happier making music on the Mac. I’ve used my 2013 laptop at plenty of live shows and haven’t had any sort of problem yet. We’ll see what happens in the next year, but I’m not ready to count macOS out as an audio workstation OS.
> I make music, and I have to say, the jump to 64 bit and the jump to macOS 11 have been pretty damaging to my workflow in the short term. My DAW, my drivers, and my plugins are all written by different developers and they all need to update for me to get fully back to work (In fairness, I made the mistake of upgrading eagerly to macOS 11, which is on me).
Apple doesn't care because they'll still get their $99/year from developers and their App Store is almost infinitely profitable.
None of the plugins or pieces of software I use had to be installed through the app store, and I think that's something of the norm there. I think managing large, required changes (like updates in processor architecture) is difficult, but I don't think I can fault Apple for going through the changes regardles.
71 comments
[ 2.9 ms ] story [ 150 ms ] threadAnyone have more detail here? What is it about the TRAKTOR KONTROL S4 MK3 that makes it vulnerable to damage via software?
I wonder how it damages them.
> I’d call it a firmware problem if the motors can be commanded to move too fast
So it sounds like they agree with you.
(Edit: typo)
Also, I initially misread this as National Instruments and imagined a DJ programming in LabView, LMAO.
This made my day. This is one of the funniest things I have ever read.
In general, it's quite common for USB device firmware to be of extremely poor quality; it'll be tested and bugs fixed until it works with the target OSes and drivers, but no comprehensive testing of whether it can deal with all possible standard request patterns is done.
Obviously you could design this sensibly so that no legal inputs result in malfunction let alone damage, but that might cost more, so, do it all in software right? And then you're at the mercy of the software and anything (such as the OS kernel) which that software depends on.
We do teach Computer Science / Software Engineering students not to do this, showing them e.g. the Therac-25 incident as an example of why software control isn't enough - but well, check out how many HN regulars are proud that they either didn't pay any attention in class or never attended and are "self-taught".
SANE (the Free Software document scanner software) has run into cases where it's just cheaper to have code that checks "Is this the end of the bed? If so, turn off the motor" than spend five cents on a limit switch or one cent adding a stop so that the scan head physically can't fall off. Somebody reverse engineering a driver sends "Move scan head" and, to their astonishment, it falls off its rail and their scanner is broken. Oops. Now, who feels comfortable shipping that to users knowing if your finished driver didn't catch every edge case you might destroy their scanner?
TWAIN (sometimes said to mean "Toolkit Without An Interesting Name") looks like it's a universal API for scanners, except, the mandatory parts just spin up a graphical user interface and that does all the actual work. There is no actual scanner technology in TWAIN, each scanner comes with its own GUI plus scanner driver bolted into one app.
So in TWAIN there is no API for like "Scan A4 document, 300dpi" only "Make whatever Twain GUI I have appear" and when you buy a scanner it just comes with a CD (I guess these days they tell you to download it probably? I have not set up a new scanner in decades) with the software on it.
But SANE does what people assumed TWAIN did, the GUI application software is neutral, and the code for driving scanners has APIs for scanning documents, because that makes more sense (and also, frankly, "reverse engineering USB code" and "building easy to use GUIs" are not the same skill set). As a bonus it means you can network SANE, just by adding an RPC layer, whereas for TWAIN you'd need like RDP or something. Blergh.
It's because companies want "superstars" (ie: underpaid people with something to prove by spending a whole bunch of unpaid overtime in order to get $50k at the end of 2-3 years when the company is sold)
The truth is in the hardware game, you end up cutting corners in order to deliver something someone will buy because if you're a dollar pricier than the next guy noone will build your plastic AF product.
That comes from a culture of engineering that focuses on learning and continuous improvement, otherwise we'd just be fixed in time the moment we left school.
Now let's say you have a high power Amp configured correctly for mixing a -24db classical music recording and then the OS glitches out and you hear 0db noise. That might blow up your speakers, headphones, or even worse, your ears.
My experience writing kernel drivers for audio software is that Windows will accept the click sound and then stop processing if the buffer runs dry. OS X used to have issues that it'll continue playing, meaning it'll reinterpret random memory as sound. Not sure if that was fixed in recent Mac versions, as their approach does have memory & performance benefits. But it means that audio driver glitches on Mac can be physically painful for the user.
I experienced one glitch like that while mixing with headphones, it's hard to describe how loud it was, a bang in my ears that made me fall and left me shackling for a few minutes. If you have ever be surprised by headphones at max volume, imagine it's even (way much) louder (because music at max volume is not a full 0db white noise). To this day I now avoid playing with plugins with the headphones and only put them for the final mix/mastering.
Judging by the comments, apparently not.
Because every update usually also moves things forward. E.g. on Big Sur they moved third party kernel extensions to userland ones. That's safer, less crash prone (an extension issue doesn't bring down the whole system), more modular, makes it possible to upgrade an extension without a reboot, and so on.
Check PC forums of pro music users how often they have issues with drivers, incompatibilities, updates, etc.
And that's not with "switching to a major new architecture" issue, or "moving kernel extensions to userland" type fairs, which are major changes and can understandably bring issues with them (but can be totally worth it long term).
It's just incompatibilities between the million different hardware combinations you can find in a PC, Windows issues, etc.
>Heck every Mac is always on a different update because they are scared to even update in Mac only cooperate networks like mine.
Actually it has been reported time and again that Macs are among the fastest percentage wise to move to the latest OS version compared to Windows PCs, with something like 70% having moved over in a couple of months...
Just because something move forward doesn't means it moves in the right direction.
> And because they still have the better OS/hardware combo.
Do they ? How many brain-time did Apple waste yesterday by soft-bricking ALL THE DAMN MACS running Canalina ?
Sure. In this case though I meant "in the right direction" too. I, for one, welcome third party kernel extensions moving to userland.
>Do they ? How many brain-time did Apple waste yesterday by soft-bricking ALL THE DAMN MACS running Canalina ?
A little. Nothing like the brain-months I've wasted on Windows and Linux troubleshooting, and I've been using Windows for ~30 years, and Linux for ~20 (plus several UNIX varieties of yore, like SunOS, Solaris, and AIX, with the ocassional toying with FreeBSD as well).
I'm annoyed by several things in Apple land as well (e.g. the keyboards on the last 3 years on laptops, the firewall bypass situation in Big Sur, the not-so-useful touch strip, and lots of minor issues), but I'm also annoyed by the "grass is greener" sentiment all the time, or the "sky is falling/Stallman was right" rhetoric...
I feel that I spend 2-3x times troubleshoot my mac than Ubuntu. I still haven't been able to find a cause for intermittent entire UI froze I experience 2-3 times a day.
Worse support experience ever, or worst experience ever?
If it was the latter, you have a pretty sweet life!
But even if it was the former, you must have had some pretty great online support experiences until that point...
Well, that's hardly the usual behavior. I have uptime in months (or had, I rebooted to switch to Big Sur).
Maybe a faulty production run? Or some suspect app?
I don't need a dark theme. I don't need to be able to answer calls from my iPhone on my Mac or whatever.
I just need the software I have paid for, that has worked for 7 consecutive software iterations, to continue to work.
I'm in the 'Snow Leopard was peak MacOS / OSX' camp, honestly; having used the OS as a daily driver since 10.3.x...
This contrasted with your last sentence is amusing because it can be applied to 10.5 (no more CE) 10.6 (no more PPC hardware) and 10.7 (no more Rosetta)
People are rejoicing when developer updates their app "fast" to support new OS, but once upon a time, one wouldn't even expect to have to update anything at all, just because "new OS version". You can easily run Win 95 app on Win 10. I can run a CNC controller built for WinXp, controlling very destructive equipment on Win7 without issue, and I've been using statically linked binaries on Linux for years without problem, so really WTF ? Are Apple fans just that blind ?
Not when millions of people rely on working computers, and as much third party peripherals.
All this is enabled by the music gear community which blindly accepts a 2k synth (e.g. Moog Matriarch or Novation Summit) to be riddled with bugs one year after release or companies like NI or Elektron to always be 6 months late with compatibility for new Mac OS releases (first Catalina, now Big Sur), shifting blame on Apple.
It's Apple's platform - they signal changes well in advance. As a developer you either support it and play by the rules or move off it.
NI hasn't even managed to update their UI to the high DPI / Retina world in many cases.
Why do software developers have to spend money because Apple keeps changing the stuff constantly?
UX retina are non-trivial changes. In the case of Qt, I recall that this meant changing the version this dropping other OS versions that were previously supported unless you duplicate all development effort.
Apple has NO incentive to not keep changing everything and breaking stuff thus forcing people to constantly upgrade and buy new hardware. For me, there weren’t any material changes in the OS I was happy and started using.
[1] is practically the same announcement by Avid Pro Tools, which is the standard for Hollywood movie production.
I also have a personal stake in this, because I used to sell pro audio software, including things that integrate with Pro Tools and OS X. We saw the writing on the wall around OS X 10.11 when major studios asked us to support Linux and subsequently bought $40k Linux-based mixing desks.
The fact is that any professional customer that uses NI has jumped ship years ago, so for Native Instruments the Mac market is shrinking in revenue, while growing in costs.
In my case, Windows and Linux are now paying for feature development. We still snort out OSX binaries from an old 10.9 xcode, but those aren't notarized because no paying customer has asked for it yet.
This is what happens if you don't value the time of your third party developers, for example with useless updates and poor documentation. I'm sure Apple will spin this as "the app store provides", but there's only so much work you can put in for a platform with a median lifetime app revenue of <$1000.
In short, professional movie studios have voted with their money, and now the market follows suit by canceling Mac support.
[1] https://avid.secure.force.com/pkb/articles/en_US/Compatibili...
For classical music and bluray mastering, I hear the most from Nuendo users on Windows. Their cheaper variant Cubase is popular for audiobook production.
For music production, BitWig and REAPER are currently the rising stars. Both are popular on Linux:
https://www.bitwig.com/download/
https://www.reaper.fm/download.php#linux_download
BitWig especially fits in with the hacker spirit because you can modify and script almost everything.
They also have many features for live shows and / or DJing. That market used to be squarely owned by Ableton on Mac, but the latter has recently fallen out of favor over plugin compatibility issues with newer effect VSTs.
For broadcast, meaning TV shows and live sports streaming, I heard that BBC and the likes are using LAWO which are custom integrated hardware+software solutions capable of loading Linux VST plugins.
https://www.lawo.de/up-to-date/news/nbsp/floating_earth_uses...
I've been modding them, taking out the processing units and replacing them with custom ones that are class compliant.
It's a shame these music hardware companies tend to do no future proofing at all sometimes.
At the same time, working on a Mac in general has been so, so much more reliable than working on windows. I used to have endless problems with dropouts or latency problems on windows, regardless of the driver, sound card, or buffer size I used. I’m sure things have improved in the time since, but I’ve been so much happier making music on the Mac. I’ve used my 2013 laptop at plenty of live shows and haven’t had any sort of problem yet. We’ll see what happens in the next year, but I’m not ready to count macOS out as an audio workstation OS.
Apple doesn't care because they'll still get their $99/year from developers and their App Store is almost infinitely profitable.