JUCE and macOS 11 / ARM

Awesome, thanks. That solves it.

Any idea why my AU would load in AudioPluginHost, pass auval, show up in Logic Plug-in Manager, but I can’t add it to a track?

Is it classified as an instrument or midi-controlled-effect and you’re adding it as an effect insert? If so can you add it as an instrument in an instrument track? Note that the classification may be faulty and refreshing may require deleting Logic’s AU caches.

1 Like

Everything provided by Apple for this transition including the DTK, Big Sur betas, pro apps seeds are covered by pretty strict NDAs. To improve support for Juce we need to discuss this stuff though and we only have a public forum in which to do it but I’m concerned we’re not really meant to, so what is the pragmatic position we’re actually in here? I’m already wondering about whether it’s ok to ask or respond to certain questions in a public forum like this.

2 Likes

Everybody who contacted me should have or will receive an invite into the ProAudio Seed program by this weekend. If you have not received an invite by Monday, please contact me personally (not in this forum, I really can not monitor it as well)

2 Likes

I ended up changing my plugin id, rebuilding and it worked. Then I changed it back and it still worked. So I guess something in the cache was wrong.

2 Likes

Probably will need to adjust the audio Thread if I understand correctly.

Rail

Is the getOperatingSystemType() correct ? When parts[0].getIntValue() == 11 I think you want to do major += 16

I’m not able to continue on jassertfalse in XCode Beta 4 / Big Sur Beta 4, also “step over” does not work, it always stays at the same position. (I guess a xcode bug)

I think this is likely due to running on ARM, rather than an Xcode bug. The nice recoverable jassertfalse behaviour is dependent on the x86 instruction set, and I haven’t yet been able to find a way of emulating the same behaviour on ARM.

1 Like

So I guess on ARM Macs it’s behaving like debugging iOS today?

Is anybody aware of any beta programmes with DAW manufacturers that are supporting Apple Silicon with support VST2 or VST3 yet? I can test in the Juce sample host, but being able to exercise VSTs in a more representative environment would be much better for stress testing. (Could be under NDA, please DM any tip-off if so and I’ll apply direct to the company).

Does/will JUCE provide any support for the SIMD instructions in the ARM architecture? If they are not supported, how is Apple silicon going to compete with the SIMD features on Intel hardware?

There’s support for NEON but afaik it uses v7/A32 intrinsics only. I guess it will be updated for A64 eventually, it’s just adding another, very similar NativeOps implementation.

Do the features in Apple’s Accelerate help you? I found vDSP and vForce a good substitute for many of the optimisations I needed, sometimes some of the problems needed thinking about a little differently, but there’s a lot in there to help with this transition.

The reported version of macOS depends on which SDK your app linked against. If it is linked against macOS 10.15 or earlier, you will see macOS 10.16 (to avoid issues with broken tests, which only test for the minor version). If you build against macOS 11.0, you will receive macOS 11.0 (which is correct)

Would it be an option to call a function-body, so its easy, by setting a breakpoint, and uncommenting one line, to re-enable the old continuing behaviour?

#elif JUCE_MAC && JUCE_CLANG && JUCE_ARM
void juce_debugbreak_arm();
  #define JUCE_BREAK_IN_DEBUGGER        { juce_debugbreak_arm(); }

in cpp-file:

void juce_debugbreak_arm()
{    // to enable continuing debug-break, remove next line and set a breakpoint on this line
   __builtin_debugtrap();
}

Anyone running JUCE AU plugins successfully on Logic ARM ? I built a plugin with “arm64” architecture, but it’s refused by Logic. On the other hand, it’s successfully validated by AUVAL, which is somehow confusing, because Logic is using AUVAL.

Logic is complaining that my plugin has “arm64e” achitecture and it can’t be loaded. I don’t use “arm64e” architecture in my project at all.

Any ideas? Unfortunately i don’t have direct access to ARM machine, yet.

You’re not the only one, I’ve seen this over at KVR here. Plug-ins I’m building under XCode 12 are showing as containing “arm64” not “arm64e” with lipo -info ‘path’, is that the case for you? If not, maybe check the Architectures are set correctly in XCode.

I am working with Zaphod (Giancarlo) together on this project :slight_smile:

All commands (file, lipo etc.) are properly showing “arm64” - absolutely no trace of “arm64e”.

I’ve doublechecked Xcode project few times - using only “arm64”.

Is this a Juce project? Do you get the same behaviour with a brand new Juce project?