Lazy developers exposed by Apple M1 transition (lack of native updates)

[FapFilter]

I'm pretty sure that any developer gets a prety early sneak peek into the new architecture. Nonetheless it can vary from something to learn, and implement to a lot of work, depending on how you made your plugin.

Of course. I didn‘t try to state otherwise, just that developers don‘t necessarily have to be hit out of the blue. I‘m also actually quite sure that most developers were already pretty aware that some of their (or licensenced) code might not work beforehand which wouldn‘t be easy fixes at all

[chk071]

I take a look into coding every now and then, and, frankly, I'm stunned that people take that amount of work and learning at all. Especially as things move so lightning fast these days. Well, not just learning the programming languages, but also gathering the knowledge about DSP from god knows where (I wouldn't know where to start, TBH).

Just saying that most people surely underestimate what a massive task all this is. They put 150 € on the counter, and then ask "Where's my M1 native plugin version" after half a year of owning it, and call the devs lazy, if they don't provide it ASAP.

Anyway, I guess you can feel entitled as a customer to a certain degree, but, calling people lazy and stuff just won't do.

[Super Piano Hater 64]

@Super Piano Hater: I don't want to do a political discourse here (...)

My actual point was that people who use that nickname for VCs typically do not intend it as a political statement.

If you have such powerful superstitions about the C word that you can't bear to see it used in a sentence without thinking of the other C word, maybe you're the one who needs to spend some time with a mirror.

Anyway. Programming. You all might enjoy this classic:

https://www.stilldrinking.com/programming-sucks

[counterparty]

I'm a dev of non-audio software by trade .

It's worth remembering that many programs that solve real-world problems are also really ugly on the inside. They start out simple and elegant but soon end up too complicated for anybody to hold the whole thing in their head at once.

As a result, changes that seem simple can actually be very complicated and time-consuming (and conversely changes that seem difficult can turn out to be very simple). Without having spent a good amount of time with the code it's difficult to estimate.

Also, keep in mind that changing processor architecture is not a trivial change for a lot of audio software. Since plugins tend to have a loop that runs thousands of times a second, devs tend to try to optimise as much as possible. Quite a lot of audio software has portions where the devs overrule the compiler (that converts the text of the source code to machine language) and actually program directly in machine instructions themselves (which let you do things like deal with several voices of a synth in one instruction etc, so it's worth it). When you suddenly start having to deal with a different type of processor these instructions are now different (and there's no guarantee that the instructions for one processor will have an identical instruction for the other, plus you also have to make sure it still sounds the same..). It's not trivial.

[chk071]

If you have such powerful superstitions about the C word that you can't bear to see it used in a sentence without thinking of the other C word, maybe you're the one who needs to spend some time with a mirror.

I don't think so.

And these are no superstitions. It's just the typical terminology. Looks like people will never learn from the past.

[jamcat]

X86 CPUs have been around since 1978 = 44 years by the end of this year
ARM CPUs since 1985 = 37 years by the end of this year

Read the reply by Aleksey from Melda, an actual developer with lots of plugins to port to M1.

Also x86 has been around for 5 decades now by my count:
1980s = 1st decade
1990s = 2nd decade
2000s = 3rd decade
2010s = 4th decade
2020s = 5th decade

{ pssst. Voxengo }

[Ploki]

@Super Piano Hater: I don't want to do a political discourse here, that's mainly the reason why I don't know why on earth the "rebels" always start with this "vulture capitalism" crap. Especially as they're usually a big part of it, with their consumer behavior. I can only recommend to point your finger at your mirror image, instead of blaming others for what they create because of you. Frankly, a lot of the depitciton here bears any real conditions anyway.

[Ploki]

Read the reply by Aleksey from Melda, an actual developer with lots of plugins to port to M1.

Also x86 has been around for 5 decades now by my count:
1980s = 1st decade
1990s = 2nd decade
2000s = 3rd decade
2010s = 4th decade
2020s = 5th decade

Let's stay fair though. ARM for home computers has only become a thing very, very recently. And, actually, only on Apple computers. It's practically non-existant on Windows machines. Probably has a market share of 1-2% on Windows, if even.

let's be super fair tho, apple has been using RISC (PowerPC) for about the same time as X86. (1990-2006 - 16 years) And Alexey actually made PowerPC plugins up until 2011.
x86/CISC was 2006-2020 - 14 years.

And lets also be more fair, apple has been doing their own chips since iphone 4 (2010) so the M1 is more like 14th gen chip than 1st gen or "bleeding edge".
First gen iphone was out in 2007, so technically apple has been using RISC from 1990 to 2020s, 4 decades!
And iPads are, for all intents and purposes a "personal computer".

Now if we're done being obtuse here, can we stop pretending that compiling for 1980s DOS-based systems has anything to do with developing in 2020s?

[Aleksey Vaneev]

"RISC" is too broad, so does not apply here (you can't use AltiVec nor pre-built PowerPC libraries on ARM).

[Ploki]

"RISC" is too broad, so does not apply here (you can't use AltiVec nor pre-built PowerPC libraries on ARM).

Yeah i assumed it is, but what libraries from 1980s x86 apply to 2020s tho?

[Aleksey Vaneev]

"RISC" is too broad, so does not apply here (you can't use AltiVec nor pre-built PowerPC libraries on ARM).

Yeah i assumed it is, but what libraries from 1980s x86 apply to 2020s tho?

I'm not getting this logic. x86 then x86-64, SSE then AVX, was a progressive adoption, no hurries as Windows supported most 32-bit and even 16-bit applications. Apple's desktop ARM64 is a disruptive change to most extablished production workflows. As was change from PowerPC to x86 (AltiVec to SSE, big-endian to little-endian, which at the time I think was a real head-ache for developers without cross-platform codebase).

[Aleksey Vaneev]

Windows 10 still runs my 32-bit Impulse Modeler, that's 16! years after its latest release. And it sells a bit as well still.

[Ploki]

Windows 10 still runs my 32-bit Impulse Modeler, that's 16! years after its latest release. And it sells a bit as well still.

i wish that was ported to mac

in any case, thanks for the insight in previous post

[Aleksey Vaneev]

I would add, for better perspective. I use about 10 third-party libraries in Voxengo plug-ins. Now imagine some much bigger application uses 100 third-party libraries (it's not an exaggeration), some with hard-coded, or even assembler, SSE/AVX, without an update in sight...

[v1o]

X86 CPUs have been around since 1978 = 44 years by the end of this year
ARM CPUs since 1985 = 37 years by the end of this year

Read the reply by Aleksey from Melda, an actual developer with lots of plugins to port to M1.

Also x86 has been around for 5 decades now by my count:
1980s = 1st decade
1990s = 2nd decade
2000s = 3rd decade
2010s = 4th decade
2020s = 5th decade

{ pssst. Voxengo }

Oops. That was a typo!