12 ms·

Don't upgrade to macOS Sonoma 14.4 yet: plug-in compatibility issues

88 points by bj-rn 3y ago

jasongill 3y ago
Note that by plug-in, they appear to be talking about plug-ins for professional audio and music production software specifically.
- bmitc 3y ago
  I was recently downvoted for describing this exact situation, and yet, here we are. This is effectively gauaranteed to happen every single macOS release.
- galad87 3y ago
  Plug-ins that use PACE / iLok protection. The irony is that the cracked versions probably are still working.
  - inferiorhuman 3y ago
    E.g. any photo editing stuff from DxO
    - diggan 3y ago
      And a ton of professional audio tools. From the top of my head: Avid/Pro Tools, Waves, iZotope, Eventide, Lexicon, Softube, and I'm sure a lot of others.
  - deleted 3y ago
    [deleted]
- bzzzt 3y ago
  It's an issue for plugins 'protected' by the iLok DRM system. It's probably not macOS, but incorrect code that accidentally worked in the past. Seems similar to the JVM situation.
  - SpaghettiCthulu 3y ago
    What JVM situation are you referring to?
    - Mashimo 3y ago
      Probably this: https://news.ycombinator.com/item?id=39741115 https://news.ycombinator.com/item?id=39741115 Some say it's a POSIX valid thing to do.
  - diggan 3y ago
    > It's probably not macOS, but incorrect code that accidentally worked in the past Well, it was correct code, as it was working, and after a macOS update, the code that used to be correct, is no longer correct. But it's not the fault of macOS, but the people who produced the code?
    - dylan604 3y ago
      Yes -- Tim Apple
    - jackcviers3 3y ago
      It's not a bug. It's a feature.
    - Someone 3y ago
      > Well, it was correct code, as it was working, I haven’t checked this case, but that’s not valid logic in general. For example, code that writes out of bounds data can be ‘working’, yet read from or write to unallocated memory, but then break when a new OS release changes the memory allocator or changes the size of some allocations. Another example are broken checks for features. If, instead of checking whether the OS or CPU supports feature ‘foo’, you check for ‘version ≥ magic_number’, assuming every OS/CPU will after that will support the feature, your program code can stop working when that assumption turns out to be incorrect. The code was broken all the time, though.
      - 3y ago
- jahnu 3y ago
  Another reason we are glad we didn't impose iLok on our customers.
whstl 3y ago
This is the kind of thing that puts me off the most about those complicated copy protection schemes. They always rely on kernel extensions, undocumented functionality and hiding a lot of stuff in your hard drive, in locations that are often in your (and Apple's) interest to protect, or even to routinely clean. I also remember some scandal a couple decades ago with some plugin scanning your /etc/hosts file for their domains. I'm pretty sure there's more egregious stuff going on. I swore off iLok about a decade ago when I had to go into a studio and couldn't get the goddamn thing to authorise anything and had to spend a few hours in support. On my local machine I could just buy stuff then immediately pirate it for stability, but on a studio that was not possible. I'm ok with other people using, but I'm tired of those software makers treating my computer as if it was their playground.
- mschuster91 3y ago
  > I also remember some scandal a couple decades ago with some plugin scanning your /etc/hosts file for their domains Given that this used to be enough to prevent Adobe CS5 and CS6 from phoning back home and detecting you used a keygen, some sort of "sanity check" against the license server endpoint IPs does make sense.
  - koolba 3y ago
    > … some sort of "sanity check" against the license server endpoint IPs does make sense. No it doesn’t. If you want to verify the response from a given endpoint, cryptographically sign the response and verify the signature. TLS + hostname verification for the license server is pretty close too (with the proviso that you’re trusting the CA cabal to not let someone else spoof you). There’s no world where it’s okay for software or even hardware to mess with networking or DNS.
    - mort96 3y ago
      > with the proviso that you’re trusting the CA cabal to not let someone else spoof you And keep in mind that usually, the user has ultimate control over the "CA cabal". Since the user is the antagonist in the world of DRM, relying only on HTTPS might not be the best idea. But then again, the whole effort of preventing the user from doing what they want on hardware and an OS they have total control over might not be the best idea in general.
Scribbd 3y ago
Has macOS been this bad in updating, or is this something of recent times? 14.2 was also a disaster for me.
- Mindwipe 3y ago
  High Sierra broke FAT32 files over 2GB which was similar levels of fun.
- aunty_helen 3y ago
  It’s always been like this. Updates are just times a bunch of stuff on you pro device stops working randomly or differently. Oh hey you now get a thumbs up bubble appear on your video call if you start counting with you thumb. “ <thumbs-up> things you need to improve as a developer…”
  - mschuster91 3y ago
    > Oh hey you now get a thumbs up bubble appear on your video call if you start counting with you thumb. That's something Zoom implemented ages ago. Out of interest, which client are you talking about?
    - Scribbd 3y ago
      It is built into macOS now, if you start using your camera, you can click the camera-icon in the top bar for more spectacular options. Link to the support page: https://support.apple.com/en-us/105117 https://support.apple.com/en-us/105117
      - lioeters 3y ago
        > Reactions fill your video frame with a 3D effect expressing how you feel. Hearts, balloons, confetti, fireworks.. Great, just what I needed built into my OS.
        dimask 3y ago
easyThrowaway 3y ago
Is this related to the same issue reported with the JVM crashing on the same update?
- TonyTrapp 3y ago
  Hard to tell if it's exactly the same, but audio plugin and DAW manufacturers warning people to upgrade to the latest macOS version because of incompatibilities is a common sight, it happens with every major macOS version at the very least. Sometimes also with minor versions, like in this case.
qwertyuiop_ 3y ago
what a bizarre site.
- bmitc 3y ago
  What's bizarre about it?
- directmusic 3y ago
  IMO cdm is a great resource for musicians. I have been reading it for close to a decade and have found many cool tools and learned a lot from it. I particularly like the DAW update summaries.
- jcelerier 3y ago
  CDM is a very standard audio industry blog
ehutch79 3y ago
If only there was a way for all these customers to test their software on upcoming versions of MacOS before it releases...
- ndrake 3y ago
  Per: https://blogs.oracle.com/java/post/java-on-macos-14-4 https://blogs.oracle.com/java/post/java-on-macos-14-4 "The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update."
  - ehutch79 3y ago
    Fair, for JVM. Audio plugins have a history of ignoring announced changes, and months of betas, and then getting surprised on release day when their plugins just don't work.
    - chedabob 3y ago
      I'd be willing to give them the benefit of the doubt in this instance, as 14.4 seems to be a duff release. Haven't seen this many major issues since High Sierra. I'm currently tracking these 3 for our staff: https://appleinsider.com/articles/24/03/14/the-macos-sonoma-144-update-is-breaking-printers-for-some-users https://appleinsider.com/articles/24/03/14/the-macos-sonoma-... https://appleinsider.com/articles/24/03/16/oracle-advises-users-delay-sonoma-update-due-to-java-issue https://appleinsider.com/articles/24/03/16/oracle-advises-us... https://appleinsider.com/articles/24/03/12/latest-macos-sonoma-update-is-breaking-some-usb-hubs-in-monitors https://appleinsider.com/articles/24/03/12/latest-macos-sono...
    - aaomidi 3y ago
      Minor version bumps shouldn’t cause these issues tbh
      - ehutch79 3y ago
        You're not wrong about that.
VyseofArcadia 3y ago
I used to work on some professional software that shipped a macOS version. macOS updates were, and I suspect still are, awful, and it's Apple's fault. Every single update we would beg our users to please, please, please, hold off on updating until we put out an update. Users would always rag on us on the forums because they assumed we were just sloppy and "why doesn't Windows have this problem". Because Microsoft doesn't subtly change the behavior of half a dozen APIs every release without warning anyone, that's why. Don't get me wrong, I despise MS, but as a developer, at least they've got that going for them. Yes I know that's not the specific issue here, but I promise you my old company is still dealing with this problem every single release.
- yardie 3y ago
  I'm an old dinosaur of a developer but I do remember enough XCode to know that it would throw enough warnings when API calls were going to be deprecated. And you could ignore those warnings and ship your binary. But eventually those warnings come true and your binary won't work in later OS releases. Microsoft was a dream to work with. They more or less made sure old API calls continued to work long after they stopped developing it. Usually just some wrapper code in their libraries to manage it automagically. Part of it I feel is Apple is quick to cut insecure APIs while Microsoft will let them linger for a while and try and patch them.
  - djxfade 3y ago
    This situation is different. This isn't about some deprecated API, but Apple changing the behaviour of the API, with no prior warning. Even the beta releases of 14.4 didn't implement this change, so no third parties actually got a chance to detect this. It's a really bad situation.
    - yardie 3y ago
      Got it, I think I understand the griping now. I've been a Mac user for decades but Sonoma is the 1st major release I can remember where everything is going to shit, even 9.x -> OSX wasn't this bad.
andybak 3y ago
Title should say Audio Unit or AU plugins for clarity.
mediumsmart 3y ago
thanks for the heads up, will stay with Monterey.
dylan604 3y ago
Before iLok and USB, there were ADB dongles. You'd daisy chain each one and then add your normal ADB devices like your keyboard/mouse cable. The company I was at would rent out it's Avid bays at night to freelancers and students. They would have to unplug the ADB cable to add/remove any dongles they needed for their work. For those unfamiliar with ADB cables, the pins were not the sturdiest. It was also very similar to the SVideo port common on Macs at the time. I found this out when I came in one morning to start prepping for a session when the keyboard/mouse didn't work. After checking the cable, I noticed the dongles were in a different order on the ADB cable. Turns out, one of the overnight users had attempted to plug the ADB chain into the SVideo and bent one of the pins on the Avid dongle. Removing the dongle allowed the computer to function, but no Avid and a client was due in 30 minutes. Dongle replacements were not something just available at the local store. It took lots of phone calls and a week's down time. Yeah, I hate physical DRM in any form whatsoever. </rant>
Terretta 3y ago
> I’m not saying technical problems are inevitable or faulting developers. I’m saying there has to be a better way of handling this quality issues – both in how changes are made and how they’re communicated. Waiting for the system to fail on users’ systems – whoever is to blame, whatever the reason – is waiting until it’s too late. The better way is a long public developer release cycle. The folks doing weirdness like blocking things from working (plug-in DRM) should have released updates long before this. I've never understood the "no, we don't update until after OS-maker releases to the public, please delay updating until every third party dev in your stack gets around to it depending on the volume of complaints", versus shipping stack component updates during the dev releases, so that when RC and general releases come out, it's all good. Well, I understand it. One of these requires funding proactive and preemptive continuous maintenance. The other is easier in a budget allocation battle: "users are broken, my team needs money to fix it." So I'm not faulting developers either, I'm faulting the tech maintenance and expense culture of the firm where the developers work.
- dmix 3y ago
  > The better way is a long public developer release cycle. The folks doing weirdness like blocking things from working (plug-in DRM) should have released updates long before this. I use beta cycles on MacOS and 14.4 was released to devs in early February, so they've had 1-2 months roughly to detect and address this. And contact Apple if there was a major issue (audio professionals are a big business for Apple). Everything I've seen about iLok...and plenty of other older VST/music companies... have a strong gleen of software teams that are either budget-tier or extremely behind the times. The UIs are the worst, often 10yrs out of date. I suspect partially because they do lazy cross-platform stuff.
  - veidr 3y ago
    Yeah, but iLok especially, but Mac music-production software as a whole always has the stench of death about it. Even the Intel->Apple CPU transition was awful, with many (super performance-intensive, latency-sensitive) audio software packages running on Rosetta for years... many years. iLok is, I think, an accidental monopolist like Adobe Flash in the era just before Steve's famous Thoughts on Flash. Terrible product, content to milk it to the end, no intention or capability of fixing it. I have a couple iLok USB sticks (that are like $75) and the only purpose of them is so my music shit (from various vendors) keeps working when iLok servers are down. But the flip side of this is this: I am just a hobbyist with no professional use of this stuff — I just love having all these (simulations/emulations of) retro guitar amps and various effectors and mixing consoles that to my (non-pro, non-audiophile) ear sound indistinguishable from the real thing, and would have cost a couple million dollars back in the 1990s. But even in my case, the dollar value of this stuff is a lot more than the Mac I run it on. So most of the time, I've had a dedicated Mac for music, and another one for work and/or life. Because historically, these music companies need more like 1-2 years, not months, to update their shit. (If they do at all; quite a lot of the music plugins and apps never make the transition — whether that is PPC to Intel, 32-bit to 64-bit, Intel to ARM, old kernel extensions to new blehpmpphblewhatev, pre-SIP to SIP, and so on and so on...) For professional use (music studios, etc) waiting to upgrade isn't that insane — the music software is the main thing, and the OS version is a secondary concern. (I wish it were otherwise.)
deleted 3y ago
[deleted]
nicwolff 3y ago
The accompanying Safari update seems to have re-broken the GitHub IDE as well – trying to select text is "off" by a few lines. This was pretty annoying when it was broken previously and I was glad for the fix in 13 – oh well...

88 points by bj-rn 3y ago

Note that by plug-in, they appear to be talking about plug-ins for professional audio and music production software specifically.

bmitc 3y ago
I was recently downvoted for describing this exact situation, and yet, here we are. This is effectively gauaranteed to happen every single macOS release.
galad87 3y ago
Plug-ins that use PACE / iLok protection. The irony is that the cracked versions probably are still working.
- inferiorhuman 3y ago
  E.g. any photo editing stuff from DxO
  - diggan 3y ago
    And a ton of professional audio tools. From the top of my head: Avid/Pro Tools, Waves, iZotope, Eventide, Lexicon, Softube, and I'm sure a lot of others.
- deleted 3y ago
  [deleted]
bzzzt 3y ago
It's an issue for plugins 'protected' by the iLok DRM system. It's probably not macOS, but incorrect code that accidentally worked in the past. Seems similar to the JVM situation.
- SpaghettiCthulu 3y ago
  What JVM situation are you referring to?
  - Mashimo 3y ago
    Probably this: https://news.ycombinator.com/item?id=39741115 https://news.ycombinator.com/item?id=39741115 Some say it's a POSIX valid thing to do.
- diggan 3y ago
  > It's probably not macOS, but incorrect code that accidentally worked in the past Well, it was correct code, as it was working, and after a macOS update, the code that used to be correct, is no longer correct. But it's not the fault of macOS, but the people who produced the code?
  - dylan604 3y ago
    Yes -- Tim Apple
  - jackcviers3 3y ago
    It's not a bug. It's a feature.
  - Someone 3y ago
    > Well, it was correct code, as it was working, I haven’t checked this case, but that’s not valid logic in general. For example, code that writes out of bounds data can be ‘working’, yet read from or write to unallocated memory, but then break when a new OS release changes the memory allocator or changes the size of some allocations. Another example are broken checks for features. If, instead of checking whether the OS or CPU supports feature ‘foo’, you check for ‘version ≥ magic_number’, assuming every OS/CPU will after that will support the feature, your program code can stop working when that assumption turns out to be incorrect. The code was broken all the time, though.
    - 3y ago
jahnu 3y ago
Another reason we are glad we didn't impose iLok on our customers.

whstl 3y ago

This is the kind of thing that puts me off the most about those complicated copy protection schemes. They always rely on kernel extensions, undocumented functionality and hiding a lot of stuff in your hard drive, in locations that are often in your (and Apple's) interest to protect, or even to routinely clean. I also remember some scandal a couple decades ago with some plugin scanning your /etc/hosts file for their domains. I'm pretty sure there's more egregious stuff going on. I swore off iLok about a decade ago when I had to go into a studio and couldn't get the goddamn thing to authorise anything and had to spend a few hours in support. On my local machine I could just buy stuff then immediately pirate it for stability, but on a studio that was not possible. I'm ok with other people using, but I'm tired of those software makers treating my computer as if it was their playground.

mschuster91 3y ago
> I also remember some scandal a couple decades ago with some plugin scanning your /etc/hosts file for their domains Given that this used to be enough to prevent Adobe CS5 and CS6 from phoning back home and detecting you used a keygen, some sort of "sanity check" against the license server endpoint IPs does make sense.
- koolba 3y ago
  > … some sort of "sanity check" against the license server endpoint IPs does make sense. No it doesn’t. If you want to verify the response from a given endpoint, cryptographically sign the response and verify the signature. TLS + hostname verification for the license server is pretty close too (with the proviso that you’re trusting the CA cabal to not let someone else spoof you). There’s no world where it’s okay for software or even hardware to mess with networking or DNS.
  - mort96 3y ago
    > with the proviso that you’re trusting the CA cabal to not let someone else spoof you And keep in mind that usually, the user has ultimate control over the "CA cabal". Since the user is the antagonist in the world of DRM, relying only on HTTPS might not be the best idea. But then again, the whole effort of preventing the user from doing what they want on hardware and an OS they have total control over might not be the best idea in general.

Scribbd 3y ago

Has macOS been this bad in updating, or is this something of recent times? 14.2 was also a disaster for me.

Mindwipe 3y ago
High Sierra broke FAT32 files over 2GB which was similar levels of fun.
aunty_helen 3y ago
It’s always been like this. Updates are just times a bunch of stuff on you pro device stops working randomly or differently. Oh hey you now get a thumbs up bubble appear on your video call if you start counting with you thumb. “ <thumbs-up> things you need to improve as a developer…”
- mschuster91 3y ago
  > Oh hey you now get a thumbs up bubble appear on your video call if you start counting with you thumb. That's something Zoom implemented ages ago. Out of interest, which client are you talking about?
  - Scribbd 3y ago
    It is built into macOS now, if you start using your camera, you can click the camera-icon in the top bar for more spectacular options. Link to the support page: https://support.apple.com/en-us/105117 https://support.apple.com/en-us/105117
    - lioeters 3y ago
      > Reactions fill your video frame with a 3D effect expressing how you feel. Hearts, balloons, confetti, fireworks.. Great, just what I needed built into my OS.
      - dimask 3y ago

easyThrowaway 3y ago

Is this related to the same issue reported with the JVM crashing on the same update?

TonyTrapp 3y ago
Hard to tell if it's exactly the same, but audio plugin and DAW manufacturers warning people to upgrade to the latest macOS version because of incompatibilities is a common sight, it happens with every major macOS version at the very least. Sometimes also with minor versions, like in this case.

qwertyuiop_ 3y ago

what a bizarre site.

bmitc 3y ago
What's bizarre about it?
directmusic 3y ago
IMO cdm is a great resource for musicians. I have been reading it for close to a decade and have found many cool tools and learned a lot from it. I particularly like the DAW update summaries.
jcelerier 3y ago
CDM is a very standard audio industry blog

ehutch79 3y ago

If only there was a way for all these customers to test their software on upcoming versions of MacOS before it releases...

ndrake 3y ago
Per: https://blogs.oracle.com/java/post/java-on-macos-14-4 https://blogs.oracle.com/java/post/java-on-macos-14-4 "The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update."
- ehutch79 3y ago
  Fair, for JVM. Audio plugins have a history of ignoring announced changes, and months of betas, and then getting surprised on release day when their plugins just don't work.
  - chedabob 3y ago
    I'd be willing to give them the benefit of the doubt in this instance, as 14.4 seems to be a duff release. Haven't seen this many major issues since High Sierra. I'm currently tracking these 3 for our staff: https://appleinsider.com/articles/24/03/14/the-macos-sonoma-144-update-is-breaking-printers-for-some-users https://appleinsider.com/articles/24/03/14/the-macos-sonoma-... https://appleinsider.com/articles/24/03/16/oracle-advises-users-delay-sonoma-update-due-to-java-issue https://appleinsider.com/articles/24/03/16/oracle-advises-us... https://appleinsider.com/articles/24/03/12/latest-macos-sonoma-update-is-breaking-some-usb-hubs-in-monitors https://appleinsider.com/articles/24/03/12/latest-macos-sono...
  - aaomidi 3y ago
    Minor version bumps shouldn’t cause these issues tbh
    - ehutch79 3y ago
      You're not wrong about that.

VyseofArcadia 3y ago

I used to work on some professional software that shipped a macOS version. macOS updates were, and I suspect still are, awful, and it's Apple's fault. Every single update we would beg our users to please, please, please, hold off on updating until we put out an update. Users would always rag on us on the forums because they assumed we were just sloppy and "why doesn't Windows have this problem". Because Microsoft doesn't subtly change the behavior of half a dozen APIs every release without warning anyone, that's why. Don't get me wrong, I despise MS, but as a developer, at least they've got that going for them. Yes I know that's not the specific issue here, but I promise you my old company is still dealing with this problem every single release.

yardie 3y ago
I'm an old dinosaur of a developer but I do remember enough XCode to know that it would throw enough warnings when API calls were going to be deprecated. And you could ignore those warnings and ship your binary. But eventually those warnings come true and your binary won't work in later OS releases. Microsoft was a dream to work with. They more or less made sure old API calls continued to work long after they stopped developing it. Usually just some wrapper code in their libraries to manage it automagically. Part of it I feel is Apple is quick to cut insecure APIs while Microsoft will let them linger for a while and try and patch them.
- djxfade 3y ago
  This situation is different. This isn't about some deprecated API, but Apple changing the behaviour of the API, with no prior warning. Even the beta releases of 14.4 didn't implement this change, so no third parties actually got a chance to detect this. It's a really bad situation.
  - yardie 3y ago
    Got it, I think I understand the griping now. I've been a Mac user for decades but Sonoma is the 1st major release I can remember where everything is going to shit, even 9.x -> OSX wasn't this bad.

andybak 3y ago

Title should say Audio Unit or AU plugins for clarity.

mediumsmart 3y ago

thanks for the heads up, will stay with Monterey.

dylan604 3y ago

Before iLok and USB, there were ADB dongles. You'd daisy chain each one and then add your normal ADB devices like your keyboard/mouse cable. The company I was at would rent out it's Avid bays at night to freelancers and students. They would have to unplug the ADB cable to add/remove any dongles they needed for their work. For those unfamiliar with ADB cables, the pins were not the sturdiest. It was also very similar to the SVideo port common on Macs at the time. I found this out when I came in one morning to start prepping for a session when the keyboard/mouse didn't work. After checking the cable, I noticed the dongles were in a different order on the ADB cable. Turns out, one of the overnight users had attempted to plug the ADB chain into the SVideo and bent one of the pins on the Avid dongle. Removing the dongle allowed the computer to function, but no Avid and a client was due in 30 minutes. Dongle replacements were not something just available at the local store. It took lots of phone calls and a week's down time. Yeah, I hate physical DRM in any form whatsoever. </rant>

Terretta 3y ago

> I’m not saying technical problems are inevitable or faulting developers. I’m saying there has to be a better way of handling this quality issues – both in how changes are made and how they’re communicated. Waiting for the system to fail on users’ systems – whoever is to blame, whatever the reason – is waiting until it’s too late. The better way is a long public developer release cycle. The folks doing weirdness like blocking things from working (plug-in DRM) should have released updates long before this. I've never understood the "no, we don't update until after OS-maker releases to the public, please delay updating until every third party dev in your stack gets around to it depending on the volume of complaints", versus shipping stack component updates during the dev releases, so that when RC and general releases come out, it's all good. Well, I understand it. One of these requires funding proactive and preemptive continuous maintenance. The other is easier in a budget allocation battle: "users are broken, my team needs money to fix it." So I'm not faulting developers either, I'm faulting the tech maintenance and expense culture of the firm where the developers work.

dmix 3y ago
> The better way is a long public developer release cycle. The folks doing weirdness like blocking things from working (plug-in DRM) should have released updates long before this. I use beta cycles on MacOS and 14.4 was released to devs in early February, so they've had 1-2 months roughly to detect and address this. And contact Apple if there was a major issue (audio professionals are a big business for Apple). Everything I've seen about iLok...and plenty of other older VST/music companies... have a strong gleen of software teams that are either budget-tier or extremely behind the times. The UIs are the worst, often 10yrs out of date. I suspect partially because they do lazy cross-platform stuff.
- veidr 3y ago
  Yeah, but iLok especially, but Mac music-production software as a whole always has the stench of death about it. Even the Intel->Apple CPU transition was awful, with many (super performance-intensive, latency-sensitive) audio software packages running on Rosetta for years... many years. iLok is, I think, an accidental monopolist like Adobe Flash in the era just before Steve's famous Thoughts on Flash. Terrible product, content to milk it to the end, no intention or capability of fixing it. I have a couple iLok USB sticks (that are like $75) and the only purpose of them is so my music shit (from various vendors) keeps working when iLok servers are down. But the flip side of this is this: I am just a hobbyist with no professional use of this stuff — I just love having all these (simulations/emulations of) retro guitar amps and various effectors and mixing consoles that to my (non-pro, non-audiophile) ear sound indistinguishable from the real thing, and would have cost a couple million dollars back in the 1990s. But even in my case, the dollar value of this stuff is a lot more than the Mac I run it on. So most of the time, I've had a dedicated Mac for music, and another one for work and/or life. Because historically, these music companies need more like 1-2 years, not months, to update their shit. (If they do at all; quite a lot of the music plugins and apps never make the transition — whether that is PPC to Intel, 32-bit to 64-bit, Intel to ARM, old kernel extensions to new blehpmpphblewhatev, pre-SIP to SIP, and so on and so on...) For professional use (music studios, etc) waiting to upgrade isn't that insane — the music software is the main thing, and the OS version is a secondary concern. (I wish it were otherwise.)

deleted 3y ago

[deleted]

nicwolff 3y ago

The accompanying Safari update seems to have re-broken the GitHub IDE as well – trying to select text is "off" by a few lines. This was pretty annoying when it was broken previously and I was glad for the fix in 13 – oh well...