JUCE - Windows for ARM - tweaks

Hi folks,

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.

Best wishes to all,

Pete

3 Likes

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 :slight_smile:

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?

FileSearchPath VST3PluginFormat::getDefaultLocationsToSearch()
{
   #if JUCE_WINDOWS
    const auto localAppData = File::getSpecialLocation (File::windowsLocalAppData)        .getFullPathName();
    const auto programFiles = File::getSpecialLocation (File::globalApplicationsDirectory).getFullPathName();
    // MARK: MPC - ARM64 (begin)
    #if defined(_M_ARM64)
    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)
   #elif JUCE_MAC
    return FileSearchPath ("~/Library/Audio/Plug-Ins/VST3;/Library/Audio/Plug-Ins/VST3");
   #else
    return FileSearchPath ("~/.vst3/;/usr/lib/vst3/;/usr/local/lib/vst3/");
   #endif
}

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! :wink:

Pete

2 Likes

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>
  <ItemGroup Condition="'$(Platform)' == 'ARM64'">
    <Content Include="Assets\blah.blah" />
  </ItemGroup>

The fix was to supply identical assets for both variants (by removing the conditionality from the group(s)).

Hoping that helps somebody,

Pete

1 Like

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 :slight_smile:

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 :slight_smile:

Best wishes, Pete

1 Like

@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.

HTH, Pete

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. :slight_smile:

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.

1 Like

https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/Locations+Format/Plugin+Locations.html

https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/Locations+Format/Plugin+Format.html

Did you also manage to build and sign your AAX plugins in this environment? I wasn’t able to install the license manager on windows arm.

Hi @kunz

Sorry to report that I only build VST3 plug-ins (and apps) under Windows.

For completeness:

  • for Windows, we only ship VST3 plug-ins (bundled with the app equivalent).
  • for macOS / iOS, we only ship AUv3 plug-ins (bundled with the app equivalent)
  • tvOS - no plug-ins - apps only!
  • Android (Amazon, Google) - no plug-ins - apps only!

Restricting to one plug-in variant per platform makes my life much easier!

Best wishes, Pete

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.

2 Likes

You are right. Too much time wasted already on this. I will keep the intel mac for linux and windows release builds for now.