Wondering how the Apple ARM transition is going to affect huge plug-in ecosystems, like DAWs and VSTs. This could go very poorly, with the effective loss of anything that isn't being actively developed and/or having to re-buy everything for ARM...
-
-
DAWs might provide compatibility shims, but that takes extra effort and I bet it'll be a niche filled by others, much like how I can run Windows VSTs on Linux with LinVST (but poorly), and there is a performance cost.
-
LMMS does it with wine. Although it's bad enough Apple dropping 32bit support and Ubuntu THINKING about dropping 32bit.
- Show replies
New conversation -
-
-
Windows for AArch64 ships some of the common libraries that are compiled for Arm, but callable from emulated x86 processes, however AFAIK, it's impossible to do that for your own code.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Emulators can make do without modifying the system. Apple is better positioned. Apple controls system libraries. They can provide interposers. There will be quirks of course, but the vast majority of binaries should work. ABI breakage happens without the need of changing arch.
-
I'm talking about plug-ins. You can't provide a generic interposer that works for arbitrary plugin interfaces. Interposers have to be written specifically for every ABI boundary. Apple can make apps work but they can't make plug-ins work with different arch apps.
- Show replies
New conversation -
-
-
This Tweet is unavailable.
-
Then I want to see their magic ABI adaptation framework, because I'm pretty sure that's an unsolvable problem generally. They might provide APIs to develop your own shim layers, but it's never going to just "magically work".
- Show replies
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.