VST3: state not restored in Ableton Live — setComponentState is not implemented

[olilarkin]

Symptom

A clap-wrapper VST3 loses its state when an Ableton Live set is reloaded: after reopening the set, all parameters show (and behave as) their default values, even though the plugin's state was saved correctly.

Diagnosis

Live's Log.txt shows what happens on set reload:

info: VST3: Going to restore: <plugin>
info: VST3: plugin processor successfully loaded: ...
info: Vst3: couldn't initialize controller with processor state of <plugin>: not implemented
info: VST3: couldn't hand processor state of <plugin> to controller: not implemented
info: VST3: Restored: <plugin>

Live restores the processor via IComponent::setState (which works — ClapAsVst3::setState forwards to clap_plugin_state.load), and then hands the same stream to the edit controller via IEditController::setComponentState to initialize its parameter view. ClapAsVst3 is a SingleComponentEffect and does not override setComponentState, so the EditController base returns kNotImplemented.

The result is that Live's parameter layer keeps the default values from plugin creation: the device panel displays defaults, and Live writes those stale values back over the plugin's freshly restored state — so the restore is effectively undone.

Why validators don't catch it

Both clap-validator (on the underlying CLAP) and pluginval at strictness 8 (including GUI + state-restoration tests) pass: neither drives the controller through setComponentState the way Live does.

Fix

Implement setComponentState: load the handed state into the CLAP plugin (idempotent when setState already ran, and covers hosts that call the controller side first), then refresh the wrapper's VST3 parameter cache from the live CLAP values — the same sync param_rescan(CLAP_PARAM_RESCAN_VALUES) performs. Verified in Ableton Live 12.4: set reload now restores correctly.

PR follows.

[Quant1um]

Wouldn't returning kResultOk from setComponentState work as well? Some frameworks (like nih-plug) seem to do just that, no need to deserialize the state twice.

[olilarkin]

Maybe - we do that in iPlug2

[CrushedPixel]

Returning kResultOk is the correct fix, but plugins are required to request parameter rescan, as this is where clap-wrapper updates EditController::parameters.

Ableton Live reads parameter values from the edit controller after loading state, while other hosts don't, which is why this mismatch only manifested in Ableton Live.

So: this is up to plugin devs to fix by synchronously calling request_rescan on the params extension if any parameters are changed during load.

[wilfreddenijs]

Another data point, on Windows 11 x64 + Ableton Live 12 Standard, clap-wrapper v0.15.1.

I hit this exact symptom and initially fixed it by backporting the setComponentState implementation from #476. That worked. But following @CrushedPixel's comment I tested the plugin-side route instead, and it turns out that alone is sufficient here:

Against stock v0.15.1, with no wrapper changes at all, calling host params.rescan(CLAP_PARAM_RESCAN_VALUES) at the end of the plugin's clap_plugin_state.load makes Live restore state correctly across a set save/reload. Verified in Live 12, with no regression in Bitwig or Cubase 15 LE. I've since removed the backport from my project entirely.

One version-specific note that may be worth checking: the report says ClapAsVst3 does not override setComponentState, so the EditController base returns kNotImplemented. On the v0.15.1 tag it is overridden:

tresult PLUGIN_API ClapAsVst3::setComponentState(IBStream * /*state*/)
{
  // this should satisfy Hosts that want to be satisfied
  return kResultOk;
}

It returns kResultOk and ignores the stream — already the behaviour @CrushedPixel describes as correct. That may explain the difference between our two logs: mine showed the state being restored and then overwritten, rather than the not implemented lines in the report. If the kNotImplemented path is coming from a different branch or an older tag, that's probably worth pinning down before deciding what the wrapper needs to do.

Not arguing against the PR — hosts that call the controller side first would still benefit from a real implementation. Just noting that on this tag, a plugin-side rescan was the whole fix, and it might be worth documenting that expectation for plugin authors either way.

[defiantnerd]

Thanks @olilarkin