Anyone know what this means, and how it impacts plugin development for Mac?
It sounds like only one build is needed for both x64 and arm64, but that seems weird.
A universal binary for mac is running natively under either intel or arm64. Only downside is that the binary is quite a bit bigger (14 vs 24Mb), but that isn’t really a problem, as at runtime only the pertinent parts for the architecture it’s running on are loaded. Been a thing since the Mac went from PowerPC to Intel CPUs
1 Like
Interesting, thanks.
That still leaves me with significant questions.
Presumably the plugin toolchain must be updated. I wonder if that has been done.
Also, where will the universal binaries be placed? Currently there are separate folders for x64 and arm64. Would the same binary be copied to both folders? - that seems silly to me.
Or will we revert to a single universal plugin folder?, which sounds like a potential upgrade nightmare, waiting for all plugins to be recompiled.
It’s one download with both architectures in it just like basically every other Mac app. But it retains per architecture plugins.
So you have one thing you can run either but based on which one you run it will download the plugin for that arch
Since plugin directories contain the architecture name this just works, it does mean though if you start the binary and download, then restart it under Rosetta, you will download a second plugin set
2 Likes
What if you have both installed already? Will it still work?
I think this might be involved with my GitHub Actions builds suddenly failing. I see this in the log:
2024-05-13T18:01:54.3884260Z --2024-05-13 18:01:54-- https://vcvrack.com/downloads/Rack-SDK-latest-mac-x64.zip
2024-05-13T18:01:54.4314050Z Resolving vcvrack.com (vcvrack.com)... 168.235.102.117
2024-05-13T18:01:54.5054460Z Connecting to vcvrack.com (vcvrack.com)|168.235.102.117|:443... connected.
2024-05-13T18:01:54.7383230Z HTTP request sent, awaiting response... 302 Found
2024-05-13T18:01:54.7387910Z Location: Rack-SDK-2.5.2-mac-x64.zip [following]
2024-05-13T18:01:54.7392640Z --2024-05-13 18:01:54-- https://vcvrack.com/downloads/Rack-SDK-2.5.2-mac-x64.zip
2024-05-13T18:01:54.7397220Z Reusing existing connection to vcvrack.com:443.
2024-05-13T18:01:54.9234330Z HTTP request sent, awaiting response... 404 Not Found
2024-05-13T18:01:54.9484220Z 2024-05-13 18:01:54 ERROR 404: Not Found.
Sure enough, when I go look at the VCV download folder, the only 2.5.2 SDK for Mac I see is:
Rack-SDK-2.5.2-mac-x64+arm64.zip
So instead of separate zip files for each platform, there is a single one. What is the best way for me to fix my GitHub Actions yml script to handle this case?
I didn’t see anything on the Automated building thread about this yet.
Update: I solved the problem using this change to my yml file. I will post more in the proper thread. Sorry for cross-post noise.
4 Likes
Thanks for sharing the fix!
I think your post very much is relevant for this topic! One of my questions concerning the change was how it affects the build process. Thanks for finding the fix and posting.
Does this affect the toolchains? Do we need to harvest new SDKs to make that work?
I think so? But only if we want to use the new multi-arch functionality?
I haven’t made any attempt to update my SDK to 2.5.2, and my mac builds are still working. But if I were to update then presumably I must make the toolchain change.
I have a more fundumental question: My DAW’s only open one of the VCV architecture plugins. I can start the standalone Intel version of VCV on my Mac… and thus access modules that only work in Intel architecture, (such as Instruo) but if I open a VCV VST2 or VST3 plugin in a DAW … I can only get the ARM version… thus no Instruo. Does this fix address that issue?
No, I don’t think so. But if you can open your DAW in “intel mode” it might propagate that choice down to the plugins opened. You’ll have to try. You might also send a very friendly email to Instruo saying “I’m really looking forward to the Intruo plugin for ARM”. What’s your DAW?