Yes I agree, that’s what was confusing me. But I don’t think JUCE has any capability of being aware that it is being used in a cross-compilation scenario (yet), so this distinction would not have come up in the past. I wonder how that might even work - might JUCE be able to detect that you sourced a non-system toolchain before invoking CMake somehow?
Anyhow, I’ll try the option you recommended and see what happens. There might be a good path to bringing @oli1 's work into the future by making it compatible with JUCE’s native CMake support.
JUCE works just fine in a Remote Host scenario where rsync is used to push all the source to the target device and build natively on the embedded target (which is simpler but a lot slower). There should be an ADC presentation from last year coming out on YouTube at some point in the coming weeks/months that can show you how to get set up that way.
As oli1 mentioned there are some embedded-specific fixes that need to be done to JUCE but you can manage those in your own fork of JUCE.
It would be great to find a way for those of us doing this to share our changes to JUCE with one another to avoid reinventing the wheel on our own.
The Pi is hindered by its buggy OpenGL implementation, and it’s hard to make it run deterministically, which will be an issue if you’re trying to create real-time audio software or trying to hit sub 10ms round trip times.
None of those examples do anything graphically intensive. Unlikely they’re leveraging OpenGL or stressing it to see the issues.
You have to be running deterministically if you create a product and advertise as real-time/zero latency. You might be able to achieve low round trip times 99% of the time, but that 1% will cause consumers not to trust your product in a live environment.
The Pi is an excellent platform for prototyping, and it can get you from 0 to 80% in a short amount of time, but that 20% will become a real problem as you try and polish it.
None of these examples push the GL capabilities - true. But GL shouldn’t be a priority, really - unless we’re trying to turn JUCE into a game engine.
As for latency and performance, I’ve not had a single dropout or glitch from either the Monome or Zynthian in my studio, and I know the ZynthianOS devs have done a lot to get the realtime capabilities of Raspian where it needs to be for their project. I wouldn’t be so pessimistic …
