Crash in Ardour about sfizz

[paulfd]

Could you try with f473539? I did indeed introduce a wrong behavior in this commit...

[alcomposer]

Yes this fixed the issue.

[x42]

What is the motivation here? The sample-rate is passed to the plugin when the plugin is instantiated and must not change. So you can pick it up directly from instantiate (...)

The parameter-option is only for the benefit of GUIs (and it is passed as atom_Float). Support for this was only added recently. Ardour 5.x did no support this option.

[paulfd]

I seem to recall that e.g. VST can change sample rates on the fly. At least such an option existed in Juce. I assumed this option was there to handle this possibility.

[x42]

Yes, VST has that option (but almost no VSTs implement this properly. Check e.g. frequency grid-lines in VSTs EQs when changing the rate).

It is also super rare that anyone would change rate of a project while running. That's not click-free, nor realtime-safe, and one cannot do this live anyway. Also many plugins allocate buffers depending on sample-rate, so LV2 opted to just take down and re-instantiate the plugin.

I'm not aware of any LV2 host that allows changing the sample-rate while running. jalv, Ardour, Qtractor don't (maybe Carla does?).

[paulfd]

I agree it seems overly optimistic to change the sample rate live, but as far as I could see there is really nothing preventing it in the way the "Options" extension is set. The API documentation mentions that the methods are in the "instantiation" threading class but that the options are there to enable changing some parameters of the plugin at runtime.

I don't remember exactly but the reason why I put this code path to change the sample rate was probably because I had an unmap around that told me that the host sent a sample rate option, and figured I probably should handle it somehow :) If I can disregard it it's fine as I already initialize the default sample rate to the parameter passed to the instantiate(...) function. Is it the same for the block size or can this actually change at runtime?

[x42]

The API documentation mentions that the methods are in the "instantiation" threading class but that the options are there to enable changing some parameters of the plugin at runtime.

Indeed. it's theoretically possible possible that way.

Is it the same for the block size or can this actually change at runtime?

Yes, it can change at runtime. A plugin must also support run(..,n_samples) for any non-negative number of n_samples. The block-size is only an upper bound.

e.g. Ardour splits the cycle when looping or when there's port-automation. So in a single process cycle of 1024 samples, the plugin may be called with run(567); /* parameter or position changes*/ run (457);

[paulfd]

Ahhh I see that's how this is implemented. It seemed weird to have only a single parameter value per block with automation curves. Thanks :D I aimed at doing it this way though so hopefully I succeeded...

My question however was more related to whether the max sample rate may change by calling set_options(...) after instantiation?