Some VST3 plugins unable to load preset data until editor UI is shown

[ben-hayes]

Hey all 😊

It seems that there exists at least one VSTi (Surge XT) where the UI needs to be rendered before setting preset data has any effect. That is, with a preset that should set the parameter "a_osc_1_type" to "Modern", the following fails:

from pedalboard import VST3Plugin

p = VST3Plugin("/Library/Audio/Plug-Ins/VST3/Surge XT.vst3")
p.load_preset("presets/surge-base.vstpreset")
assert p.a_osc_1_type == "Modern"  # AssertionError

And the following works:

p = VST3Plugin("/Library/Audio/Plug-Ins/VST3/Surge XT.vst3")
p.show_editor()  # then manually or programmatically close editor
p.load_preset("presets/surge-base.vstpreset")
assert p.a_osc_1_type == "Modern"  # All good!

However, it doesn't seem that opening the UI will cause previously loaded preset data to have an effect:

# However...
p = VST3Plugin("/Library/Audio/Plug-Ins/VST3/Surge XT.vst3")
p.load_preset("presets/surge-base.vstpreset")
p.show_editor()  # then manually or programmatically close editor
assert p.a_osc_1_type == "Modern"  # AssertionError again...

I would guess this is related to #233, in that some crucial state is initialised on the UI thread, although interestingly the following doesn't work:

import matplotlib.pyplot as plt
p = VST3Plugin("/Library/Audio/Plug-Ins/VST3/Surge XT.vst3")
plt.plot([]); plt.show()
p.load_preset("presets/surge-base.vstpreset")
assert p.a_osc_1_type == "Modern"  # AssertionError

It's not the end of the world as the KeyboardInterrupt workaround does the job, but just thought I'd bring yet-another-ungodly-audio-plugin-edge-case to your attention 😇

Cheers!

[psobot]

@ben-hayes! Great to hear from you.

I think I know why this happens; technically, Pedalboard is non-conformant to the VST3 Host spec, as we only use one thread for everything. The spec says that plugins should expect to be called from multiple threads (one for UI/events, one for audio rendering) and that the main thread runs an event loop. We've had a couple small issues like this before, and I've "fixed" them by manually pumping the event loop after certain operations; this might be fixable just with a small time-limited juce::MessageManager::run call after load_preset.

I can't commit to any specific timeline for looking into this at the moment, but this might be a fairly quick fix (and I'd be very open to PRs if you or anybody else were to put one up 😀)