> 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.
> 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.
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.
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.