Is the CLAP automation not working correctly for the part immediately after playback?

[lewloiwc]

It does not appear to be processed correctly within the first buffer after pressing the playback button.
https://github.com/baconpaul/clap-c99-distortion
https://nakst.gitlab.io/tutorial/clap-part-2.html
The light blue is measured using these two and the red is JSFX


The buffer size is 8, red indicates that CLAP_EVENT_PARAM_VALUE was called, and light blue is the parameter value.


Chowdhury I looked at the DSP BYOD and it appears that I am able to get the first value in the buffer that I could not get in the two CLAPs, but I only seem to get the value once in the first buffer.
Red is BYOD for Chowdhury DSP and light blue are the two CLAPs.

The only thing that is not smooth is the first buffer, otherwise it looks normal.


Windows 10 Home | REAPER v6.79+dev0508/win64

Translated with www.DeepL.com/Translator (free version)

[schwa]

Is it possible the plugins you are testing with are not handling clap_plugin_params::flush() ?

[lewloiwc]

CLAPi: I checked with Surge XT (Surge Synth Team) and this too was not getting parameters in the first buffer.

I don't think Surge XT is not handling clap_plugin_params::flush() correctly...

Purple is the value of Bitwig's parameter, green is the number of times Bitwig called CLAP_EVENT_PARAM_VALUE in the buffer, light blue is the value of REAPER's parameter and red is the number of times REAPER called CLAP_EVENT_PARAM_VALUE in the buffer

Bitwig calls CLAP_EVENT_PARAM_VALUE when it senses that a parameter has changed, even in the first buffer. (The distorted purple shape is probably a bug in Bitwig. This has been reported to https://github.com/free-audio/clap/issues/324)
REAPER does not call CLAP_EVENT_PARAM_VALUE on the first buffer even if the parameter has changed.
Perhaps this is the problem.

RPP used to verify Surge XT: https://drive.google.com/file/d/1-Nm...ew?usp=sharing

Translated with www.DeepL.com/Translator (free version)

[lewloiwc]

https://github.com/free-audio/clap/b...p/ext/params.h

// Note: if the plugin is processing, then the process() call will already achieve the
// parameter update (bi-directional), so a call to flush isn't required, also be aware
// that the plugin may use the sample offset in process(), while this information would be
// lost within flush().

Could this possibly mean that the part processed by flush() cannot update parameters faster than buffer size?

Translated with www.DeepL.com/Translator (free version)

[lewloiwc]

I have been mistaken.
Bitwig does not execute flush() when the playback button is pressed.
So I think I was getting some accurate values even at the moment the playback button was pressed.

Also, when I was examining flush() in REAPER, I was able to get all the values in the first buffer by using an array, but the sample offset information was lost as written in params.h.


Is this probably the best way to do it in REAPER, where flush() is executed every time the play button is pressed?

Translated with www.DeepL.com/Translator (free version)

[schwa]

The latest REAPER development builds (6.79+dev0518 and later) should have improved behavior, if you'd care to check it out. If you do, please post any feedback in the pre-release thread: https://forum.cockos.com/showthread.php?t=279256