Just to report that, if interested, I now additionally build Wotja for Windows with an ARM64 target. It was pretty easy to patch JUCE to do this.
I just added a few uses of defined(_M_ARM64) in these two files:
juce_win32_SystemStats.cpp
VectorOpsComplex.cpp
The reason I do this? Building and debugging UWP packaged apps for ARM64 (debugging using M1 Mac running Windows for ARM).
NB: if you try to install an .msixbundle file on an ARM Windows machine, where the .msixbundle only contains Intel code, it’ll refuse unless it also contains ARM64 binary.
I would really love it if JUCE gets patched to support Windows for ARM for the same purposes (easier debugging on M1-series Macs which I believe many of us use).
Thank you!
TBH this isn’t a “Business” need for me that I would want to fork JUCE for, but it would certainly be a quality of life improvement if the JUCE team would have that in at some point, especially with M1 computers being so popular.
@eyalamir FWIW, I’ve done all my JUCE development over the past several years using Macs running Parallels with Windows VMs. And now, I use M1 Macs for this.
I found that Visual Studio on M1 (with Parallels Windows for ARM) even worked fine when debugging x64 target (!) thanks to recent changes in Windows. Which is great. It means that, for example, Cakewalk works fine for me on M1 Mac under Windows for ARM, even though it is x64 code; and I can debug my x64 VST3 in that context just fine.
However, because I distribute Wotja through Microsoft’s store as a UWP-based app, and because the bundling of that app means the the outer bundle (app wrapper) doesn’t run on ARM Windows for x64 target (just a quirk of their system, but fair enough!), that meant that I needed to patch JUCE for ARM64.
Hope that was of info, anyhow
I think that if more JUCE devs distributed their apps through the Microsoft Store, this would become pretty essential. I’m still puzzled that more devs don’t do this
@reuk Can we make a feature request from this thread?
Arm seems to be the future, and MS just released the Preview Edition for Visual Studio arm 2022 native.
On a related note, how would developers distribute VST3 binaries for both x64 and ARM64?
Yes, I’m aware that there is probably near zero actual user base for ARM64 VST3 plug-ins under Windows at the moment.
For Wotja, this is a UWP app and we have the two binaries as Assets in the distribution, that can be copied-out by the app into the appropriate location(s) depending on the user’s architecture.
On WOA (windows on arm) the vst3 plugins would probably just go to “Program Files (Arm)\Common Files\VST3” while the x64 go to “Program Files\Common Files\VST3” as usual, but I highly doubt any host currently checks the arm folder.
Thanks for the information. I like the idea of reducing the number of supported plugin formats. Maybe we also leave AAX support in the future. This would make things super simple. But at the moment I really hope for a solution.
Does anyone else have a solution for iLok AAX signing on a Windows ARM machine or is it possible to sign the windows aax on macOS?
You probably need another virtual machine for the pace signing - running x64-intel windows. As far as I know, Qemu and derived apps can do it. However at that point it’s probably less painful to just use a regular windows machine - which is needed for testing anyway.