CLAP parameter modulation LFO shape (FIXED)

[Tale]

While testing prereleases of our plugins in CLAP format I came across a possible bug with CLAP and REAPR's LFO parameter modulation.

Steps to reproduce:

1. Load CLAPi: Kee Bass.
2. Toggle on/off switch in GUI e.g. Tone Mellow/Bright.
3. Click to Param > Parameter Modulation/MIDI link to show parameter modulation for Tone parameter.
4. Enable LFO.
5. Change Shape; notice that only square actually works.
6. Repeat steps 2..5 for Bass Booster lever. Notice that all shapes work.
7. Click to Kee Bass settings view, repeat steps 2..5 for Prio parameter (or other 3-way toggle switch). Notice that all shapes work, but it only uses values 0 and 1, and only ever reaches value 2 when shape is square.

For both VST2 and AU all LFO shapes work, even if the parameter is stepped, so I guess this is a off-by-one bug in REAPER's CLAP implementation, although it could also be a bug in Kee Bass.

Tested with Kee Bass v1.2.0 RC1 in REAPER v6.71 on both Windows 10 x64 and macOS 12.6.2 M1.

[schwa]

I don't see a bug here. If the plugin reports that the parameter is stepped, certain behaviors change in REAPER. The easiest way to see this is to display an envelope for the parameter.

[Tale]

Well, if I do this for the Prio parameter, which has 3 steps, then both VST2 and CLAP show an envelope with 3 steps. However, if I modulate that parameter using a triangular LFO at 0.25 Hz, then with VST2 this will result in the following repeating sequence:

0 = Low (1 second)
1 = High (1 second)
2 = Last (1 second)
1 = High (1 second)

But if I do the same with CLAP, then I get this repeating sequence:

0 = Low (1 second)
1 = High (2 seconds)
0 = Low (1 second)

Like I said, it never reaches the 3rd value. IMHO what VST2 (and AU) do makes more sense.

Also, because it seems to go from 0..N-2 instead of 0..N-1 (where N = number of steps), for parameters with only 2 steps it actually always stays at 0. I'd say this makes the random LFO shape a lot less random...

[schwa]

OK, couple of things happening I think.

The CLAP plugin supports CLAP_PARAM_IS_STEPPED, but the VST does not seem to support effGetParameterProperties, which is why REAPER knows the CLAP parameter is stepped but doesn't know the VST parameter is stepped. That's fine though, it's not required for the VST to support effGetParameterProperties.

Given CLAP_PARAM_IS_STEPPED, I think the plugin should quantize the parameter range rather than just taking the floor. With an integer range of [0,2], if the host sets a floating point value > 1.33.. [edit: more simply, >= 1.5], the plugin should quantize it to 2. This is what happens when the host tries to change the Prio parameter:

get 2.000000
set 1.998000
get 1.000000
set 0.998000
get 0.000000

[Tale]

Originally Posted by schwa

Give CLAP_PARAM_IS_STEPPED, I think the plugin should quantize the parameter range rather than just taking the floor.

Oh I see... Yeah, that seems to fix it, thanks! So no bug indeed, at least not in REAPER, but rather in Kee Bass. I do still have to verify this doesn't break something else, but it's looking promising.

Originally Posted by schwa

Given an integer range of [0,2], if the host sets a floating point value > 1.33.., the plugin should quantize it to 2.

I think I will be rounding >= 1.5 to 2, because this is what my IPlug fork seems to do elsewhere (and changing it there might break stuff). Anyhow, with this rounding in place the triangle LFO seems to do exactly what I would expect/described earlier.

Originally Posted by schwa

The CLAP plugin supports CLAP_PARAM_IS_STEPPED, but the VST does not seem to support effGetParameterProperties, which is why REAPER knows the CLAP parameter is stepped but doesn't know the VST parameter is stepped. That's fine though, it's not required for the VST to support effGetParameterProperties.

Really? Because I do support effGetParameterProperties, but REAPER never seems to call it. Other hosts do call it, so I always kinda concluded that it's REAPER that doesn't support effGetParameterProperties. Should we investigate this further?

[schwa]

Originally Posted by Tale

I do support effGetParameterProperties, but REAPER never seems to call it. Other hosts do call it, so I always kinda concluded that it's REAPER that doesn't support effGetParameterProperties. Should we investigate this further?

REAPER definitely calls it. The plugin returns 0 and doesn't alter the passed-in struct.

[Tale]

Originally Posted by schwa

REAPER definitely calls it. The plugin returns 0 and doesn't alter the passed-in struct.

Just to be sure: What is your value for effGetParameterProperties? Mine is 56.

I ask because I just logged the opcodes for all calls to my VSTDispatcher when loading VSTi: Kee Bass (in REAPER v6.72rc8 on macOS M1), and I really don't see opcode 56.

[schwa]

56, yes. The call won't happen unless it's needed, so you'd need to do something like display a track envelope for the Prio parameter.

[Tale]

Oops, I expected it to call it on loading. Anyway, yeah now I see the call, but AFAICT I am in fact altering the struct, and returning 1.

This is my code (from IPlugVST2.cpp):

VstParameterProperties* const pp = (VstParameterProperties*)ptr;
const IParam* const pParam = _this->GetParam(idx);
vst_strncpy(pp->label, pParam->GetNameForHost(), kVstMaxLabelLen);
switch (pParam->Type())
{
	case IParam::kTypeBool:
	{
		pp->flags = kVstParameterIsSwitch;
		break;
	}
	case IParam::kTypeEnum:
	{
		pp->flags = kVstParameterUsesIntegerMinMax | kVstParameterUsesIntStep;
		pp->minInteger = 0;
		pp->maxInteger = ((const IEnumParam*)pParam)->NEnums() - 1;
		pp->largeStepInteger = pp->stepInteger = 1;
		break;
	}
}
static const int len = kVstMaxShortLabelLen;
vst_strncpy(pp->shortLabel, pParam->GetNameForHost(len), len);
ret = 1;

If you happen to spot something wrong with this, then do let me know. Else I will investigate some more tomorrow on Windows (because there I can check my effGetParameterProperties implementation in e.g. VSTHost).

[schwa]

My plugin was version 1.0.1. I updated to 1.1.0 and now effGetParameterProperties is supported.

[Tale]

Oops, sorry for the confusion, but I did say that I was using Kee Bass v1.2.0 RC1, and I've linked it in the OP.

Anyway, mystery solved then, thanks!

[Tale]

BTW, although rounding stepped CLAP parameter values seems like a good idea, and fixes my issue, I think it might be against the spec. Here is what CLAP's params.h has to say about it:

// Is this param stepped? (integer values only)
// if so the double value is converted to integer using a cast (equivalent to trunc).
CLAP_PARAM_IS_STEPPED = 1 << 0,

The "equivalent to trunc" part to me suggest we should be rounding down i.e. (int)x, not (int)(x + 0.5). But if I keep doing that, then I can't fix the LFO parameter modulation at my end.

[schwa]

Hm, I will bring this up in the CLAP discussion group. I think the trunc recommendation should be changed to round.

[schwa]

Here's the discussion on the CLAP github:
https://github.com/free-audio/clap/issues/242

We'll change it so REAPER rounds the values before handing them to the plugin, so it shouldn't matter whether the plugin uses round or floor.

[Tale]

Thanks!

[Tale]

Fixed in REAPER v6.72.