Closed sjoerdvankreel closed 1 year ago
The parameters have a min and a max value, which is not necessarily between 0 and 1. in the VST3 wrapper they are scaled to appropriate ranges 0..1 and vice versa.
Just to double-check - so where vst3 has 3 parameter representations, clap has only 2? Not that that's a bad thing btw, just want to make sure.
it kind of has one. A float with a min and a max.
That float can be stepped, in which case the expectation is the min and max are integers.
You could then use the to/from string methods on param to functionally make the stepped string values
but internally: float, min/max, properties is the representation
If you choose to use 0...1 and scale yourself the API allows but you don't have to!
Thanks, it is clear to me now. Internally for my plug parameters look like "union { float, int }" (int for stepped stuff) with no boundaries so it should not be a problem to map them to an "unbounded" double and just ditch the whole [0..1] normalized idea.
-cheers, sjoerd
The only issue is if they are truly unbounded so like min and max are numeric limits then the sliders and knobs in daws will work badly. Advertising the bound sets the linear scale for, say, the bitwig gutter or automation lanes
Sorry if this has been asked before.
Coming from a vst3 background, I found there were 3 ways to represent parameters:
In the clap sdk I see the value_to_text and text_to_value functions so that takes care of (3), but i'm not sure if there is any distinction between (1) and (2)? In params.h i see comments like "// min/max/default plain value" but i can't figure out if "plain" here means "plain" in the vst3 sense. Is there anything like vst3's Steinberg::Vst::Parameter::toPlain/toNormalized or do i only have to deal with numeric vs text representation?