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

https://cdm.link/2024/03/ffs-pace/

by bj-rn • 2 years ago

88 76 2 years ago

jasongill• 2 years ago

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

galad87• 2 years ago

Plug-ins that use PACE / iLok protection. The irony is that the cracked versions probably are still working.

inferiorhuman• 2 years ago

E.g. any photo editing stuff from DxO

bzzzt2• 2 years 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• 2 years ago

What JVM situation are you referring to?

diggan3• 2 years 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?

subtra3t2• 2 years ago

Seems similar to the JVM situation

Oracle was relying on behaviour that was POSIX valid so I don't see how it is "incorrect code".

tumult• 2 years ago

There are issues for ones that don't use iLok or any bad DRM system at all. Kilohearts plugins, for example. 14.4 is bad, Apple makes it harder and harder to not have your computer updated (including forcing major OS upgrades on users back in January and bypassing password authentication to do it, linked to multiple times here) and their software quality is not so good these days.

gkbrk• 2 years ago

Is it similar to the JVM situation? The JVM situation is just a macOS bug.

jahnu• 2 years ago

Another reason we are glad we didn't impose iLok on our customers.

bmitc2• 2 years 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.

whstl3• 2 years 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.

mschuster913• 2 years 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• 2 years 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.

greggsy• 2 years ago

The USB licensing dongles used in Cubase [1] were clunky and annoying, but were pretty effective. A lot easier to manage than Flex-LM, assuming you weren't roaming around too much.

[1] https://www.steinberg.net/elicenser/

easyThrowaway2• 2 years ago

iLok, even when it was just a dongle-only protection, had a 100% chance of crashing and/or not working at all in any live setup I can think of. I learned the hard way about always exporting any stem of any track to lip-sync them as a last resort.

Even to this day I've kept the habit of doing any production or live stuff on a dedicated, offline-only box, and treat it as if it were an analog synth or dsp.

whstl3• 2 years ago

You're totally right. In a studio, a bit of downtime or crashing is not good, but used to be just a "fact of life".

Live? Different matter altogether.

I never did sound live professionally, but I still perform. I don't even have third-party plugins in Mainstage anymore.

veidr3• 2 years ago

Wholeheartedly agree with you, but I want to check my own understanding, which is: iLok became this weird monopoly because it let all the makers of actual music software stop doing all this weird shit, right? Like hiding registration details on your computer, making hardware dongles, etc.

Back in the ... 1990s, I think? It was like Cubase had their dongle, Studio Vision had... I forget, but something... but eventually they just mostly all went iLok. I dabble in music computer stuff for fun, and I feel like outside of Linux, it has been 15 years or so that it is basically just de facto all-iLok. Even though I am buying from like 10 or more companies.

I feel like we are now to the "inevitable result" part of any company gaining that kind of monopoly.

whstl3• 2 years ago

There's also some companies that moved away from it. I think Waves, and all the companies in Plugin Alliance.

I try to "vote with my wallet" for those cases. Now I'd rather not have something that is cool but requires iLok.

BXlnt2EachOther• 2 years ago

yes, Cubase used a parallel port dongle in the 90s and then in the 2000s a not-iLok USB dongle called eLicenser. They have switched to software activation for their products since 2022.

Scribbd2• 2 years ago

Has macOS been this bad in updating, or is this something of recent times?

14.2 was also a disaster for me.

aunty_helen• 2 years 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…”

mschuster913• 2 years 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?

teddyh• 2 years ago

Clearly implemented by non-European developers: <https://en.wikipedia.org/w/index.php?title=Finger-counting&o...>

Mindwipe• 2 years ago

High Sierra broke FAT32 files over 2GB which was similar levels of fun.

pzo2• 2 years ago

it's getting worse and worse with apple software quality - the latest Xcode is so broken and they haven't fixed it properly since release in september[0] - I have to turn off VPN both on mobile and desktop and turn off wifi on iphone to force deploying debug apps via cable...

[0] https://developer.apple.com/forums/thread/737875

sandoze• 2 years ago

Broken or broken in your use case? I recently left corporate development for the start up life. As I recall we had to disable our VPN for the majority of development use cases, from package management (gradle), robotics comms, all the way down to running third party unsigned software (I received a stern email from security for downloading Apple’s OpenAPI package).

Our security chain was so deeply embedded in every part of the OS that I was constantly trying to figure out where the failures and slow downs were coming from.

easyThrowaway2• 2 years ago

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

TonyTrapp• 2 years 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_• 2 years ago

what a bizarre site.

bmitc2• 2 years ago

What's bizarre about it?

directmusic• 2 years 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• 2 years ago

CDM is a very standard audio industry blog

ehutch793• 2 years ago

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

ndrake• 2 years ago

Per: 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."

ehutch793• 2 years 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.

VyseofArcadia3• 2 years 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.

yardie2• 2 years 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• 2 years 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.

tuyiown2• 2 years ago

I'd really like to have some specific example, because while apple never kept much backward compatibility, I've not eared of or being impacted much by supported API changes when used in intended ways.

The actual thing you can praise MS for is to respect the «all observable behaviors» in their backward compatibility or support. Apple never ever gave in that way, only that you are supposed to use things as expected or expect to be punished. Not that they have stellar track records on that front either, there are tons of old code that still work out there.

VyseofArcadia3• 2 years ago

The specific example I remember (because I'm the one that fixed it) had something to do with how Image I/O handled TGA images. I don't remember all the details, but it was definitely not the case that we were misusing the API. Per the documentation everything had been above board, and everything was still above board. The images causing the issue were well-formed. Just something subtly changed with the CGImageSource API for TGA images specifically that required finding a workaround.

Why that customer was using TGA images in their workflow in the 2010s I'll never know.

AdamN• 2 years ago

The beta period is at least a month long and Xcode shows you deprecation warnings years ahead on this stuff. I get that there are corner case bugs that might happen once every few years but if this is happening 'every single release' your users are right.

VyseofArcadia3• 2 years ago

Not a deprecation. I'm talking about undocumented changes in supported APIs.

Every single release may have been an exaggeration, but I was at the company three years and saw this happen more than once.

Terretta2• 2 years ago

Every single update we would beg our users to please, please, please, hold off on updating until we put out an update.

This order of operations is wrong.

andybak• 2 years ago

Title should say Audio Unit or AU plugins for clarity.

mediumsmart• 2 years ago

thanks for the heads up, will stay with Monterey.

dylan6042• 2 years 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>

Terretta2• 2 years 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• 2 years 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.

veidr3• 2 years 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.)

nicwolff• 2 years 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...

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

Related Stories