wvshpr wrote: Thu Mar 10, 2022 12:55 pm Agreed. My patience is running out. If your software isn‘t native by now, you don‘t care.
I‘ll just sell what ever is not native, when I get my Mac Studio by the end of the month. Time for a spring cleaning.
I don't know of a way to say this without sounding like a dick, but I'll try.davestretch wrote: Thu Mar 10, 2022 1:04 pm All of Waves plugins run on the same framework so it was easier for them to move over to Silicon. However, I'm pissed at how long it has taken to get even this far. I've never understood how small developers like Valhalla and Analog Obsession had M1 stuff ready to go within a few months and the big boys like Plugin Alliance (although imminent) and IK Multimedia T-Racks stuff haven't appeared. Oh, and iZotope deserve a mention here. RX9 is now Native but why they released it in October without M1 Native at launch I just can't understand.
Heck, all developers should not even be releasing new plugins if they don't include a Native version from day 1.
First, my credentials: I am the CIO of a medium sized company (750 employees). I am a developer, and run development teams. I am a network, linux, windows, and Mac system admin. I deal with multiple OSs, architectures, cloud deployments, on-prem, the works. I deal not only with the technical details, but the economics of development on a daily basis.
Development is not the neat world you think it is, and what is true of one codebase is utterly irrelevant to others.
The ability of any given piece of software to be ported to a new architecture depends on a lot of things. If your code is self-contained, that is, it does not rely upon external dependencies of which you have no control, and if your code does not contain architecture-specific code (assembly, vector extensions such as AVX, etc.,) then porting can be as simple as re-compiling. Can be, but not guaranteed to be.
If all of your plugins rely upon a common DSP core (as is the case with Melda, Waves, u-He, and likely Valhalla and FF) then even if you have architecture-specific code, you have far less to port, and can thus release a large number of plugins at once.
But if your code relies upon external dependencies such as DRM (iLok), DSP libraries, UI libraries, etc., you are at the mercy of 3rd parties to upgrade, and if you do not want to wait for them, or if the 3rd parties don't intend to port, then you have to re-implement those dependencies yourself, or migrate to alternatives. That takes a lot more time than you might think.
Or if your code has a lot of fine-tuned assembly specific to Intel, all of that has to be completely re-written. Intel and Arm assembly are apples and oranges.
Or if your code supports processor-specific extensions that do not port directly to a different architecture (such as AVX), then you need to reimplement those portions to the equivalent alternative on the new architecture (NEON on Arm). This is often not as simple as just enabling a compiler flag.
If your code is very old, with lots of cruft and workarounds (as often happens with legacy codebases), the job is much harder, because that cruft suddenly becomes relevant on different architectures. This means a lot more re-engineering such that the resulting code base efficiently supports multiple architectures without compromise.
Further, the time it takes to port is not only a function of the nature of your code, but of the development resources you have available. In other words: economics.
What looks to you like a big company from their snazzy website is most often smoke and mirrors. You are often dealing with companies that are small, and probably only have 1-3 developers who also have day jobs because niche audio software is not as profitable as you think. They simply don't have the money to hire and onboard additional help without putting the entire company at risk. Furthermore, to do these ports they need to put other projects on hold, projects that would make them new sales. They will not make new sales on the ports beyond what they are already making. They have to port to maintain their existing customer base, and secure the future of their software for new users on new architectures. In other words, all that time and effort burns cash and produces no income.
And we have Rosetta2 for the time being. So since Rosetta2 exists, and the economic pressures are what they are, for many of these shops it is absolutely the right move to devote limited resources to any such port vs. going into the red, and bankrupting the company.
Add to all of the above the cluster f*ck that Steinberg is forcing on the entire industry with the veiled threats about VST2 on M1. This means developers who have not already done so need to implement VST3, which is a really big deal and not remotely simple.
So, please, consider more than your desire to have your particular plugin native. There's a lot more to this. It's not the simple world you make it, and any outrage or frustration you might have is uninformed, and unhelpful.
