[LV2] How to handle sample rate changes?

[Robin Gareus]

On 10/03/2016 10:47 PM, Stefan Westerfeld wrote:
>    Hi!
> 
> I'm considering adding LV2 Instrument support to BEAST. Unlike qtractor or
> Ardour, BEAST doesn't have a concept of project|session sample rate.  It is
> renegotiated every time the user presses play, and thus subject to change. Now
> the standard LV2 API doesn't allow me to change the sample rate at runtime, as
> it is set during initialization.

If the SR is negotiated when you press "play", there's already some
overhead and it's not realtime. I suggest to simply re-instantiate the
plugin while you're at it.

The downside is that custom GUIs will also need to be re-instantiated,
then again those won't respond anyway if the plugin itself is not
running (during your host's "stopped" mode).

> After some research I found the LV2 Options Interface, and the possibilty to
> dynamically supply the plugin with a new sample rate. So is this the way to do
> it?

Theoretically yes, though this would require dedicated support by every
plugin.

> I suspect that many plugins will assume that the sample rate is constant,
> because the standard LV2 API suggests it. Should we in this case file feature
> requests?

http://lv2plug.in/doc/html/group__lv2core.html#a8dbb1fd9ebae0477a11dfc4f0a685d72
says explicitly that the sample-rate is per instance. It's not a
"suggests", is it?

All major plugin-standards (VST, AU, ..., LV2) expect a fixed
sample-rate which is given at instantiation time (the plugin can
allocate buffers, pre-calculate time-constants, setup filter-banks,
convert samples,... etc). For most DSP, changing the SR is not realtime
safe and requires re-initialization.

While you could file a feature request for an extension-interface to
inform plugins about SR changes, I doubt may plugin authors will
implement it.

Ports that have the property http://lv2plug.in/ns/lv2core/#sampleRate
will need to be re-set and plugin-latency may change.

In case of an EQ with GUI for example, not only the filters will need to
be re-calculated but also the GUI-Grid, transfer function display and
possible FFT (EQ with spectrum-display) will have to be updated
dynamically.  Convolvers would need to resample the IR, Synths
re-generate the wavetables, Reverbs reset the delaylines,...
Frankly, it's a can of worms.

2c,
robin

PS. curious: How does BEAST handle automation? in [fractional] seconds
instead of samples or musical time?