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:
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.
Best wishes to all,
Thank you for saying that!
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).
@eyalamir happy if it has been of some help
I’ve also made this small patch. I’d be interested to know if others are looking in the same location for VST3 ARM64 binaries?
const auto localAppData = File::getSpecialLocation (File::windowsLocalAppData) .getFullPathName();
const auto programFiles = File::getSpecialLocation (File::globalApplicationsDirectory).getFullPathName();
// MARK: MPC - ARM64 (begin)
return FileSearchPath(juce::String(localAppData + "\\Programs\\Common\\VST3;").replace("Program Files", "Program Files (Arm)") +
juce::String(programFiles + "\\Common Files\\VST3").replace("Program Files", "Program Files (Arm)"));
#else // // defined(_M_ARM64)
return FileSearchPath (localAppData + "\\Programs\\Common\\VST3;" + programFiles + "\\Common Files\\VST3");
#endif // defined(_M_ARM64)
// MARK: MPC - ARM64 (end)
return FileSearchPath ("~/Library/Audio/Plug-Ins/VST3;/Library/Audio/Plug-Ins/VST3");
return FileSearchPath ("~/.vst3/;/usr/lib/vst3/;/usr/local/lib/vst3/");
And it really didn’t take me long to patch-up JUCE for this to work. So, you might be tempted to give it a go yourself!
BTW, I found a really weird error when building UWP App Packages for upload to the Microsoft Store.
The error was shown when trying to install on x64 (but weirdly, not on ARM64!).
App installation failed with error message: Merge failure for shared merged PRI file : error 0x80070490
The problem was that I had different Assets for ARM64/x64 variants (defined using a conditional group in the project file).
<ItemGroup Condition="'$(Platform)' == 'x64'">
<Content Include="Assets\blah.blah" />
<ItemGroup Condition="'$(Platform)' == 'ARM64'">
<Content Include="Assets\blah.blah" />
The fix was to supply identical assets for both variants (by removing the conditionality from the group(s)).
Hoping that helps somebody,
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
Best wishes, Pete
@eyalamir FWIW, you might also find this post https://forum.juce.com/t/juce-avoiding-lnk1248-structuring-windows-builds/52049 of interest, where I say how I structure my Solution for building the various Windows Wotja variants.
Yes arm whohoo!
@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.