Missing call to initialise VST3 plugin for Take FX causes latency issues (FIXED)

[Ehs]

Issue:
When using action - Item: Glue items, ignoring time selection, Reaper does not initialise the plugins. Plugins with Latency will either cause injected silence or discard samples.

This is particularly troublesome for our users working on game audio using Reaper.

Repro steps:
+Add a short sample with a quick onset as an sample item.
+action - Item: Show FX chain for item take
+Add a plugin that has a variable latency (pm me if you need something, I am using UrsaDSP Boost VST3 beta 1.5.9)
- This will call initialize() and setupProcessing() and then setActive() twice all of which filter through to juce::AudioProcessor:repareToPlay() which is good as this can set the latency.

+Change the plugin latency - in Boost just make the attack / lookahead longer e.g. 40ms
+action - Item: Glue items, ignoring time selection
- this does NOT re-init the plugin. The plugin then adjusts the latency during IAudioProcessorrocess and Reaper ends up injecting samples.

I have a feeling that the above might be intermittent*. If it works as expected (without the bug) then follow these additional steps.

+action - Edit:undo (revert the glue and bring back the take FX chain)
+Change the plugin latency from long to short - in Boost just make the attack the other extreme e.g. toggle 40ms <-> 2ms
+action - Item: Glue items, ignoring time selection

+Repeat from undo if required.

---

Possible solutions:
Please either re-init the plugin before action - Item: Glue items.
OR
It might offer better plugin compatibilty to process a blank block (after the parameters are updated) to allow plugins that only set latency in the process method to stabilize ahead of glueing the item.
*I suspect you are already doing this, however that blank block is not sent in some cases (after the action - Edit:undo)


Thanks for a great DAW and thanks especially for not being one of the DAWs that tries to forbid debugging!

Dave

[Ehs]

Issue in action: https://www.youtube.com/watch?v=FWzqeaqEaNo

[ArchimonDe]

I can confirm this bug on my side.

[Ehs]

I have retested, the issue is still present in 6.65 and 6.66rc1

Please let me know if you need additional information or repro steps.

Thanks,
Dave

[schwa]

If you press the [+] button at the top of the plugin UI, under compatibility settings, is "hard reset on playback start" enabled? If enabled, the plugin should receive setupProcessing(), etc. If disabled (default), then playback start only triggers stopProcessing/startProcessing in order to flush buffers. Does it handle your issue to enable hard reset for these plugins?

[Ehs]

Originally Posted by schwa

If you press the [+] button at the top of the plugin UI, under compatibility settings, is "hard reset on playback start" enabled? If enabled, the plugin should receive setupProcessing(), etc. If disabled (default), then playback start only triggers stopProcessing/startProcessing in order to flush buffers. Does it handle your issue to enable hard reset for these plugins?

Hi,
Thanks for the suggestion, but unfortunately that doesn't change the behaviour.

Note that on playback (or on render) this works as expected - Reaper calls prepare to play (regardless of wheter that option is ticked) and, I think it also processes a block of silence with the updated parameters to allow the plugin to update latency.

It is only when glueing an item that has item FX that the issue occurs. The plugin changes latency in response to the users' parameter changes during the first block and I'm assuming that the PDC does not cope with this as there is either silence or missing samples where that first block should have been.

Thanks,
Dave

[schwa]

I've looked into this more and I think this is something the plugin needs to handle differently. At present, when the user does something on the UI that changes the latency, the plugin does not call IComponentHandler:: restartComponent(kLatencyChanged) until *during* the next call to IAudioProcessor:: process(). Even if I add a call to IAudioProcessor:: getLatencySamples() immediately after IAudioProcessor:: setActive(), the new value is not returned.

This means that the host is not informed of the latency change until after the first buffer block has been sent to the plugin. I think this happens in all FX contexts, but it's not necessarily noticeable in a track FX context, because the plugin is processing constantly.

The only way I can think of for the host to handle this is to always assume the latency may have changed before every call to process(), which shouldn't be necessary because kLatencyChanged does exist. But as a worst case backstop, we could possibly add that check when the user has enabled buggy plugin compatibility mode for the plugin.

But the correct fix I think is for the plugin to send the kLatencyChanged notification before processing starts. I would guess the reason this plugin waits is that it wants to send the notification from the audio thread, but if playback is stopped, there's no reason not to send the notification from the main thread.

[Ehs]

Fantastic info, thankyou for looking into this.

In response to the original user's bug report I modified the plugin to set latency in the initial prepareToPlay method (which I believe corresponds to IAudioProcessor:: setActive())

You can get that beta (v1.5.9) here: https://deviousmachines.com/boost-downloads/

Note that I do not believe the JUCE framework guarantees that parameters are updated / available until AudioProcessor:rocessBlock (https://docs.juce.com/master/classAu...c4bc97326dcb58 e.g. IAudioProcessor:: process()) is called.

This presents a bit of a conundrum as I (and I'd bet a fair few other plugins that use lookahead) cannot set the latency until they know what lookahead the user's parameters require.

Let me know if that doesn't make sense,
Dave

[schwa]

You might want to ping @reuk here or post an issue over on the JUCE github to see if there's an already established way to do what you need to do.

[Ehs]

It would be super helpful if Reaper could either:
1. call IAudioProcessor:: setActive() prior to glueing item fx (especially if 'hard reset on playback start' was ticked). This is something that Boost 1.5.9 now caters for as per my previous message.
or
2. push a blank block through the plugin chain prior to rendering it, which is something I think reaper does when playback starts?

I'll definitely chase up the conundrum side of things with the JUCE team, but I'm not sure if they will change in future versions of JUCE, nor would it affect all the plugins that are already out there.

HTH,
Dave

[Ehs]

Hi,

I've checked this in v6.67 and “Hard reset on playback start” now works when Glueing items with take FX.

This option with Boost 1.5.9 which is available as a beta release solves the problems of our users.

Thanks for your help with this,
Dave @ UrsaDSP