Not updating LV2 control input ports upon program change in native UI

[terminator356]

Bug Description: Surge does not appear to be updating its LV2 controller input ports upon program changes done from the GUI.

Surge XT Version Surge XT 1.2.3.bb8dd2b

• Version: 1.2.3
• Plugin Type: LV2
• Bitness: 64-bit

Reproduction Steps: In QTractor or MusE, open Surge's native GUI and the corresponding QTractor or MusE generic GUI. Now change program in Surge by selecting a program or clicking program up/down or category up/down. Observe that all the native GUI controls correctly change to new positions but the generic GUI controls do not change at all.

Expected Behavior: Generic GUI controls should follow what the native GUI shows after a program change initiated inside the native GUI.

Screenshots:

Computer Information (please complete the following!):

• OS: OpenSuse Tumbleweed
• Host: Either QTractor or MusE
• Version: QTractor 0.9.33 or MusE 4.1 release or latest master

Additional Information: In LV2 lv2extprg.h, there is this statement (nearly identical to the old DSSI statement):

     * A plugin is permitted to re-write the values of its input
     * control ports when select_program is called. The host should
     * re-read the input control port values and update its own
     * records appropriately. (This is the only circumstance in which
     * a LV2 plugin is allowed to modify its own control-input ports.)

Trouble is, Surge does not seem to have any midi programs with which I can test that statement by selecting a program from within our host. But also, this bug report is such that changing programs from within Surge GUI also does not appear to be updating its input control ports. When we instantiate a UI descriptor, we pass a callback for the LV2UI_Write_Function argument. Most LV2 synths seem to call this when a program changes via the GUI. That lets us re-read the input ports and update our records. But Surge does not appear to calling this upon program changes.

Meanwhile, Surge seems to be one of the only plugins to call the 'program_changed' callback in the _LV2_Programs_Host structure. This is good. But... Upon the 'program_changed' callback, when I examine all the input control ports so that I may update our records, none of the input ports have changed at all to reflect what is now on screen in the native GUI.

Thus, it appears impossible for us to determine what is the new state of the on screen GUI controls after a program change from within the GUI, so that we may update our records.

This behaviour is seen in both MusE and QTractor. Other synths tested do update the generic GUI controls after a program change from within the GUI.

Thanks.

[mkruselj]

Surge unfortunately doesn't handle LV2 very well in a number of aspects. VST3 or CLAP is recommended instead. We will stop distributing LV2 binary with the following Surge XT 1.3 release.

We welcome pull requests that are LV2 related, though.

[baconpaul]

Yeah unfortunately the 1.2.3 LV2 uses the community fork of juce 6, which has never really worked and is no longer supported. Our results with 1.3 with the JUCE 7 LV2 are mixed also, so we are moving that to self-build. I don't think there's even pull request you could do to surge, @mkruselj

The solution here is to use the CLAP or VST3 support in QTractor. I know the QTractor team used the surge clap when testing their implementation.

[terminator356]

Yep, I hear ya. Thanks for the responses. I know it's not entirely Surge's problem when Juce is used, like a lot of other plugins.

I just read that LV2 seems to be officially supported in Juce now. Hopefully problems can be resolved. I hope you keep trying.

As for MusE, well, we're getting requests for VST3 support, so it is overdue. (Ugh. Another architecture to support. That's five now. And CLAP will make it six.)

I will try QTractor with CLAP. Thanks for that tip.

Should I close this or leave it open for now as a reference in case others have this problem? Cheers. Tim.

[baconpaul]

Juce7 lv2 uses extensions which make it work poorly in reaper iirc. But you can build it at head with surge and try! Our users have a diverse enough env that the binary is more support than benefit.

[baconpaul]

https://github.com/surge-synthesizer/surge#building-an-lv2 If you want

[baconpaul]

Oh also the binary doesn’t build in our ci since it runs the plugin for the lv2 requirement that you have to dump the params you happen to have at build time into a ttl. This seemed to core out for us. Just in case you are curious in what we experienced!

the clap works great and clap hosting is really quite easy! Vst3 hosting though is harder work. You have my sympathies

[mkruselj]

Juce7 lv2 uses extensions which make it work poorly in reaper iirc. But you can build it at head with surge and try! Our users have a diverse enough env that the binary is more support than benefit.

Apparently Cockos folks are working on supporting that other LV2 parameter thing (was it called atoms?) for Reaper 7, so JUCE 7 LV2s could work properly.

[baconpaul]

yeah basically: if Juce 7 makes a surge lv2 which runs reliably in carla and reaper both, and CI doesn't crash, we could turn it back on in the linux bundle. For now I think document self-build approach and keep it out of the binary and wait until the LV2 community rallies around it working is our best stance as far as surge users getting a working and enjoyable experience (and our support burden being minimized).

I think we should close this issue; we aren't going to fix 1.2.3 and 1.3 probably works way better except in daws where it doesn't work at all. If anyone disagrees though feel free to reopen it!