RTAS has had deprecation warnings for years. If you attempt to build an RTAS plug-in now it won’t work. I don’t think we need to communicate that any more clearly.
Xcode 10.1, our new minimum supported version, cannot build 32-bit binaries (which includes Carbon). If you are relying upon 32-bit macOS binaries Xcode will communicate the problem to you.
Thanks, I’ve debugged Monique LV2 a bit. I’m pretty sure that both of the issues you mentioned are on the hosting side.
For the Ardour issue: JUCE plugins need to know their maximum processing block size, so JUCE LV2 plugins declare bufs:boundedBlockSize as an lv2:requiredFeature. If a plugin requires features that cannot be supplied by the host, the host should not attempt to instantiate the plugin. If the host does supply the feature, then it should include the feature in the array of features passed to the plugin during instantiation. For that assertion to fire, one of the following must be true:
For the Carla issue: JUCE LV2 UIs support opts:interface to allow the scaleFactor option to be updated dynamically after creating a UI instance. This is an optional feature, and is declared as such in the manifest. The host is free to ignore this feature, but then UIs may not resize properly when they are dragged between screens with different DPIs.
While debugging Monique LV2 in Carla, I also noticed that the behaviour is a bit different to the Monique VST3. Specifically, the LV2 didn’t produce any sound unless I started playback from Carla’s transport options; the VST3 produces sound even when playback has not been started. Monique will only process when it receives valid CurrentPositionInfo. JUCE’s VST3 wrapper will always return true from getCurrentPosition, whether or not the host passes a Vst::ProcessContext, but the LV2 wrapper will return false from getCurrentPosition if the host has not provided time info for the current callback. From the docs for AudioPlayHead, I think the LV2 implementation is more correct, but updating the VST3 implementation to match would be a breaking change. I’m still considering the best way forward here.
Please could you be a bit more specific about the behaviour you’re currently seeing, and the behaviour you’d expect to see? Are you using licensed versions of the plugins, or are you using demo copies? If the issue affects a specific plugin, please let me know which one.
On Ubuntu 22.04, I downloaded a copy of Mixbus, and then copied the Harrison.lv2 bundle into my local ~/.lv2 directory. After that, I rescanned all LV2 plugins in the AudioPluginHost. The Harrison XT plugins showed up in the plugin list, and I tried and succeeded in creating instances of XT-CC, XT-BC, and XT-EQ.
For all of these plugins:
When I look at the docs for XT-CC, I see this:
This plugin requires a license to enable the control panel.
Assuming we’re both seeing the same behaviour, I think it might be intentional. It sounds like the plugin editors are not fully functional when the plugins are running in demo mode.
Well first thank you!
we should scan all our plugs and check the getpositioninfo response. Sounds like it will be a recurring problem. Agree changing the api is probably not right but if the get returns a bool we should check it.
On ardour: Presume you are chatting with x42 and folks but if not I could flag this to them! Just let me know.
Monique does check the response of getPositionInfo, but it just bypasses most of the processing callback if no info could be retrieved. I think I’d probably expect it to use some other ‘fallback’ time info instead (maybe an internal samplecount-since-prepare or similar).
No, I haven’t communicated with the Ardour team. I’d really appreciate it if you could pass that on!
Yeah all our other synths use a fallback internal clock if there’s no transport. Monique should too. (We are still in the get-it-to-modern phase of rehab with monique).
I sent a flag over to x42 and falk in linux audio devs and they know about this thread now!
The XT plugin UI does not update parameter knobs by itself, but expects to be notified by the host in response to a change request.
The View and Controller are separate, and the host has the model.
The plugin UI sends a touch event, and then ask the host to change a parameter value. The host then should notify the plugin GUI about the new value if the change succeeded.
e.g. If a parameter is automated by the host, the value may not change in response to a UI request, and the GUI need not be updated.
Thanks, that’s helpful. It sounds like the JUCE hosting implementation needs a bit more work in that case. I should have tested the same plugins in some other hosts to check whether they work as expected.
FWIW the editors of XT-BC and XT-CC update in response to mouse interaction in REAPER 6.56, so the JUCE implementation is definitely at fault. I tried running some XT-* plugins in Carla 2.4.2 as well, but none of the editors that I tried would open (again, testing on Ubuntu 22.04). I haven’t dug into that yet, so I’m unsure whether the issue is in the host or client side, but thought you might want to know about it.
Assuming we’re both seeing the same behaviour, I think it might be intentional. It sounds like the plugin editors are not fully functional when the plugins are running in demo mode.
Sorry for not being clear. I have these plugins registered and they work in other hosts. In the Carla also:
x42 is here, I believe he can help much more that I 
The DSP is fully functional (no license noise) and the only limitation is that the GUI fades to black after a minute and asks for a license-key. Re-opening the UI resets that timer.
Caveat: The most widespread version of the plugins (those bundled with Ardour 6.9.0 from August 2021) have a bug. They assume the host implements the http://lv2plug.in/ns/extensions/ui#touch interface. If that is not present, instantiating the UI will crash. – I guess that’s why the UI doesn’t work in Carla.
Anyway as mentioned above the issue is likely due to missing feedback from the host.
The reference host (jalv) does this periodically and unconditionally for every port. Other hosts only send a value when an actual parameter change occurs.
Most LV2 plugins update the view by themselves to provide instant feedback to the user and only later re-synchronize with the actual value when the host provides it. This is an implementation choice by the plugin developer.
I’ve pushed some updates to the LV2 implementation.
This patch fixes an issue I saw in Monique, where we would run out of atom buffer space because the plugin sometimes sends change notifications for all of its parameters in one go. We now set a minimum suggested buffer size based on the number of parameters in the plugin’s manifest:
This patch sets sensible default parameter values for parameters that don’t supply their own defaults:
This change causes the host to notify the plugin editor about any applied parameter changes, even for changes originating from the editor, which should fix the issue observed with the Harrison XT plugin editors.
Support for writing and hosting ARA enabled plugins is now out on the preview branch.
Plugins with ARA capabilities enabled can communicate with ARA enabled hosts to gain “offline” access to a lot of information about the DAW project that they are a part of, including random access to all the audio source data.
In order to use the ARA features in JUCE you have to obtain the 2.1.0 version of the ARA_SDK separately. The easiest way to do this is to use the following git command, which will check out the SDK into the ARA_SDK directory.
git clone --recursive --branch releases/2.1.0 https://github.com/Celemony/ARA_SDK
Then you need to specify the SDK path in either
juce_set_ara_sdk_path function in your CMakeLists file,If you are building the examples and extras with CMake from the JUCE repo directory, you can also specify the -DJUCE_GLOBAL_ARA_SDK_PATH=/your/path/to/ARA_SDK parameter to CMake to enable ARA.
The AudioPluginHost now has simple ARA hosting capabilities, but you need to explicitly enable this support. You can do this in the following ways
JUCE_PLUGINHOST_ARA=1 inside AudioPluginHost/CMakeLists.txt
AudioPluginHost.jucer go to Modules → juce_audio_processors and enable the JUCE_PLUGINHOST_ARA setting.ARA capable plugins will now have two entries in the Create plugin menu, and the one saying (ARA) will activate additional ARA features. If you right click on the plugin in the graph, you can use the “Show ARA host control” item to assign an audio file that the plugin can read through the ARA interfaces.
If you are using CMake and provide the -DJUCE_BUILD_EXAMPLES=ON -DJUCE_GLOBAL_ARA_SDK_PATH=/your/path/to/ARA_SDK options to CMake, then you should be able to build the enabled ARAPluginDemo target.
You can also open the Plugins/ARAPluginDemo example in the Projucer.
ARA provides an extensive API that allows you to exchange information with the host in completely new ways. To understand the basics and to build up your knowledge it’s best to read the official ARA documentation, which has approachable introductory sections. You can find the documentation in the SDK directory at ARA_SDK/ARA_Library/html_docs/index.html.
IS_ARA_EFFECT TRUE to your juce_add_plugin call.In addition to the createPluginFilter() function that is needed for all audio plugins, you will now need to provide an implementation to the createARAFactory() function as well. You can do this by inheriting from juce::ARADocumentControllerSpecialisation and using its helper function. The class documentation should make this clear by also providing an example. You can also find an example in the ARAPluginDemo.
That’s so great! I’m already developing a plugin with Juce and the ARA extension. and it works fine but ARA included in the main repository will simplify things a lot. Thank you so much I’ll try it as soon as Juce 7 is released (I can’t use the MIT license for this project, unfortunately).
What’s preventing you trying it out?
The GPLv3 gives you a lot of freedom as long as you don’t distribute a closed source binary outside of your organisation. If your plug-in is in development and you’re not already distributing closed source products there’s unlikely to be anything getting in your way unless you have unusual licensing requirements.
Sorry, I meant GPLv3… and yes, that’s a closed source product and it’s already distributed privately to a few people and the public beta version can be released soon (in fact I don’t know 
but I prefer not to take the risk).
Which linker flags are needed? I’m facing the same issue.
Decided to try out this branch today and I’ve tried re-exporting and I’m being able to compile still. A bit stumped as to what I need to add!
Edit: I’m even having problems with the demos.
Are you using a build of the Projucer from the juce7 branch to save/export the projects?
Ah thanks, that was it. I naively looked at the version number and didn’t think it would make a difference…
First impressions of the graphics rendering is really good, great stuff!
Interesting find - I display a waveform in one of my plugins which used to be done in openGL. Its now drawing fantastically in most hosts using the JUCE renderer as an animated app component.
However, if “Enable graphics hardware acceleration” is turned on in Studio One, repaints become extremely sporadic; sometimes it takes a couple of seconds to repaint. Not sure if this is a JUCE or Studio One issue? Continuous mouse movement over the top of the plugin however makes it repaint as normal.
(Monterey M1 Mac mini)
