Hi, I have discovered a curious problem today with the following setup:
2019 MacBook Pro running Big Sur 11.6.1
4th Gen iPad Air as a 2nd screen using SideCar
The issue is that if the iPad is running as the 2nd screen when standalone plugin starts this is the result:
It’s a curious issue:
- SideCar running = OpenGL fails to work
- SideCar running without OpenGL attachment code = everything renders as expected
- Disconnect SideCar → start Stand Alone Plugin → reconnect SideCar = everything renders as expected (even on the iPad screen)
- SideCar running also makes OpenGL break when running inside DAW (tested with AU/Logic)
No SideCar in Logic:
SideCar running in Logic:
NewProjectAudioProcessorEditor::NewProjectAudioProcessorEditor (NewProjectAudioProcessor& p)
: AudioProcessorEditor (&p), audioProcessor (p)
// comment out the following and everything works as expected
if(auto* peer = getPeer())
// Make sure that before the constructor has finished, you've set the
// editor's size to whatever you need it to be.
setSize (400, 300);
Attached a minimal example, although of course you’ll need a compatible iPad to be able to debug this problem.
glproblem.zip (7.4 KB)
Gentle bump in case this got lost amongst ADC attendance. This affects all plugins built with JUCE (eg. Vital) and is somewhat frustrating. I hope it can be solved without too much pain.
Thanks, I can reproduce the issue on Monterey but not on Catalina. I also tried out a GLFW example on Monterey, and found that although the window updates correctly when it is on the main display, it doesn’t seem to refresh/repaint when moved to the iPad.
It looks to me like there’s a bit of work to do in JUCE to determine why apps don’t render OpenGL at all on Monterey when SideCar is enabled (I’ve added this to my backlog, but I’m not sure when I’ll get around to investigating) - I think it should be possible for them to work correctly as long as they are displaying on the built-in screen. Even then, it looks like it might not be possible for views using OpenGL to update correctly when they are displaying on an iPad via SideCar. If you’re aware of any OpenGL apps that do update correctly in this scenario, please let me know.
In my case it was Big Sur and the issue is on both the built in screen and iPad.
If I “disconnect SideCar → start the app → reconnect SideCar” then everything works, so I suspect it’s something about the initialisation of the OpenGL context that is causing the issue.
Serum is working fine when SideCar is connected, but no way of knowing for sure if it is using OpenGL.
Do you have any suggestions for a non-JUCE plugin or app I can test that is for sure using OpenGL?
For plugins, I believe that DISTRHO renders using OpenGL so you could try out some of those plugins: GitHub - DISTRHO/Mini-Series: DISTRHO Mini-Series
For a standalone app, the GLFW examples are quite lightweight and render using OpenGL. I tested the ‘particles’ demo: GitHub - glfw/glfw: A multi-platform library for OpenGL, OpenGL ES, Vulkan, window and input
I was unable to get the plugins to work, I tried the PingPongPan and it just crashed at startup in every host I tried regardless of SideCar being enabled or not.
The Particles demo of GLFW did however work, but would not update whilst the window was on the iPad.
But at least was able to see the effect whilst it was on the main screen, which is better than the current state of affairs with JUCE whereby cannot see anything on either screen.
Just to reiterate: If I start a JUCE plugin without SideCar connected (I just tried with Vital) then the UI is displayed, and continues to function after reconnecting SideCar, even when the plugin UI is on the iPad.
However starting the plugin whilst SideCar is connected results in a blank plugin UI.
IIRC also FabFilter which got some limited demo modes can be used for basic OpenGL testing.
Has any more work been done on this? Wasn’t sure if it was happening in another thread or something, I am still seeing this issue.