I’m getting a crash when launching the juce demo runner with JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS enabled. I’m on macOS mojave, macbook pro 2015 model.
The crash happens at line 239 of juce_mac_CGMetalLayerRenderer.h:
Also seeing the following metal validation error in the console: validateMTLStorageMode, line 240: error 'invalid storageMode (0). Must be one of MTLStorageModeManaged(1) MTLStorageModePrivate(2)'
Am i missing something? I don’t know a whole lot about Metal rendering.
Apologies if this was already mentioned and we missed it: is it possible to get Metal-based render callback in JUCE 7? We’d love to see support for it.
I also got a UI freeze when the low battery message popped up in iOS. I pressed ok and that’s it - the interface just hung, but the application continues to work. I used the attached branch at the very beginning of the topic.
QUESTION: Do I need to make my Root Component as OpenGLAppComponent to use Metal ?
QUESTION 2: I noticed doubling the RAM. With an Juce 6 I had 109 MB, but now 208 MB. With OpenGLAppComponent ~320mb. Is this expected ? Is it possible to return the old size by disabling something somehow?
I also got a UI freeze when the low battery message popped up in iOS
Is that a consequence of the juce7 branch?
Do I need to make my Root Component as OpenGLAppComponent to use Metal ?
Please read the posts by the JUCE team in this thread. We are using normal CoreGraphics drawing commands on a Metal layer if, and only if, JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS is enabled. Enable this option if you think you might benefit from avoiding having Apple consolidate your drawing regions. If you are using OpenGL then you will use the OpenGL renderer.
I noticed doubling the RAM. With an Juce 6 I had 109 MB, but now 208 MB. With OpenGLAppComponent ~320mb. Is this expected ?
This isn’t intentional. Where is the extra memory being allocated?
Hi @reuk
Sorry for long response. I found some new problems with LV2 host part:
rncbc https://www.rncbc.org/drupal/ plugins have GUI and sound, but doesn’t receive input properly. I can’t set values with keyboard in the main windows, but mouse clicks works on knobs and all boxes. “New/Open/Save preset” buttons didn’t reacts to clicks and preset select dropmenu also. In AudioPluginHost output there is just one warning: QWidgetWindow(0x40f6290, name="padthv1widgetWindow") must be a top level window.
perhaps like something is not complete with XCB input and window stack.
1.1 These plugins also ignores any preferences set in configuration windows, although all values where set (with key/mouse) they didn’t load on the next open of the configuration window.
Are you aware of any hosts that properly support these plugins?
Carla seems to load Synthv1 correctly, although modifying the theme of the plugin also updates the theme of the entire Carla application.
Qtractor behaves in the same way as Carla. The Synthv1 editor works, but setting a new theme on the plugin reskins the entire app.
REAPER 6.60 fares less well - I see the same keyboard-handling issue there, and in addition the host window becomes completely unresponsive after loading the synthv1 editor.
Ardour 6.9 can’t load the Synthv1 editor at all (the log shows “[ERROR]: failed to instantiate LV2 GUI” each time I try to open the UI). I can’t load the editors for LSP LV2, Dragonfly Reverb LV2, or B.Oops LV2 plugins either, although Calf LV2 UIs and Dragonfly Reverb VST UIs do work. Maybe my install of Ardour is broken somehow.
Like Synthv1, I’m pretty sure that Qtractor and Carla both use QT for their UI. I suspect that these hosts are accidentally sharing some state with the plugin, causing the weird theming behaviour. It may also be that some keyboard-handling component is shared with the host, allowing keyboard input to work in these hosts, but not in non-QT-based hosts.
At the moment, I’m inclined to say that this bug is on Synthv1’s side. I’ll investigate further if you have reason to believe that these plugins should work in a non-QT-based host.
Yes, host transport should be supported. I also tried out Bsequencer LV2 in BespokeSynth built from the juce7 branch, and it seemed to respond correctly to the host time information. Changing the tempo in Bespoke caused Bsequencer’s playhead indicator to move at different speeds, and I verified that it produced MIDI notes on its control output. That said, playback only seemed to work the first time I changed the “Mode” control to “Host-controlled playback”. Changing it to a different mode and back broke playback. I’m not sure exactly why that is - a breakpoint in preparePortsForRun still gets hit, indicating that timing information is being written to the plugin’s control input. Perhaps there’s a bug in the plugin?
In the case of stepseq.lv2, it looks like the plugin is receiving an empty event stream for some reason. I haven’t managed to get to the bottom of this yet - I’ll update here once I know what’s going wrong.
In Carla I can confirm that color theme behavior and a file dialog takes up to ~6 seconds to appear. Carla 2.4.3 from HEAD
In Reaper it loads and main UI is responsive, file dialog opens for a ~6 seconds too, and keyboard input is unavailable. Reaper 6.60
In Ardour it works almost as in Carla, key pressed, file dialog opens but a bit weird - main window hides then dialog appears after ~6 seconds. Ardour 6.9 build from Show multimedia:apps / ardour - openSUSE Build Service
I’ll message above issues to Rui, perhaps he’ll give a shot.
Can I ask what’s your distro and where you get synthv1? I recommend to use rncbc official repo: Install package home:rncbc / synthv1-lv2
They’re Qt statically linked though it should be in any other builds. Dynamic GUI linking is bad afaik
Glad to hear that transport works in Bespoke. I’ll try to find what’s wrong at my side.
This isn’t intentional. Where is the extra memory being allocated?
Not sure how to check it, I’m not good at profiling. But I’m sure 99% it’s something allocated for a GUI
Some screenshots attached. All what I did is changed JUCE folder with JUCE7 from a github>juce7 branch. Code was not changed at all. The only I added “Metal” framework in the xcode, because it doesn’t compiled.
As JUCE and CLAP share some DNA, both being open source projects, and both generally working to advance the free movement of plugins between DAWs, it would be nice to see JUCE out front leading the adoption of CLAP, rather than sitting back and waiting for DAWs to act first.
+1
I also think CLAP should have a high priority. It has so many advantages compared to other company-based plug-in formats.
IMHO the most important point is the liberal license and that this format already has a community of developers that have an open ear for feedback. This is a good basis to use the format on every OS and hardware device. CLAP also solves problems and restrictions we have with the current plugin formats.
First plugins are available and there is already a JUCE module, but we need it integrated into the JUCE framework like the other plugin formats, including the host part.
For me, this now has a much higher priority than LV2. CLAP hopefully also replaces LV2 on Linux and hardware devices in the future.
