Parameters stored as readable

[Nowhk]

Hi all,

I'm thinking to switch a bit the logic of Param within IPlug, working always with normalized values and return (when needed) the converted (readable) value. Now it seems it works mainly with readable.

Also the values stored/serialized in the presets are readable. Is there any reasons why them and not normalized ones? (which mean an additional and probably useless) conversion.

[Andi!]

Why should normalized values used in the presets? The values in IParam are also readable and when serializing params I see no conversion. At some point you have to convert normalized to readable values anyway: when reporting them to the host.

[Nowhk]

Originally Posted by Andi!

Why should normalized values used in the presets?

Why shouldn't?

Originally Posted by Andi!

The values in IParam are also readable and when serializing params I see no conversion. At some point you have to convert normalized to readable values anyway: when reporting them to the host.

The problem is that you set normalized value (in both case, via Host or GUI/IControl) and I (personally) use only normalized values within plugin/audio processing.

How do you smooth params if not with normalized values? I dunno you use a 1pole filter IIR on "real values". The same for automations: you always go between 0 and 1, THAN (only in the end) you need to wrap on "real value".

Thus, at the moment, control/host set values as normalized, which are than converted on IParam in real values (1 step of "round error"), than I re-convert on normalized (another step), process it (smooth+automation), and than re-re-convert in real value (another step of quantization error).

Basically I use 90% of the times normalized values, converting them often. Also storing on presets will go back/forth one time from real/normalized (having a loss of data so). That's why I feel logic stay always in normalized domain.

If all was normalized, you only quantize one time (when you need to process audio on calculated parameter, after smooth and automation). No less in store, no less in smooth/automation/set.

[Nowhk]

Bump?

[Andi!]

Thanks for the bump. :-) Nobody is complaining, you could try to change the behaviour. For me (and maybe dozens others) I had no problems with the rounding "quantization" errors in the past. Most important thing to me would be a massive test with Win/Mac VST2/3, AU and AAX formats including automation read/write and project saving/loading in "all" DAWs.

[ynohtna]

Worrying about the additional conversion in your use case smells like premature optimization to me, mate.

Parameters change infrequently relative to all the computation performed for each audio sample, at least for non-trivial plugins. (Conversely, trivial plugins don't expose as many parameters for automation.)

The first rule of optimisation is: don't worry unnecessarily. The second rule is: profile!

[Nowhk]

Originally Posted by ynohtna

Worrying about the additional conversion in your use case smells like premature optimization to me, mate.

Parameters change infrequently relative to all the computation performed for each audio sample, at least for non-trivial plugins. (Conversely, trivial plugins don't expose as many parameters for automation.)

The first rule of optimisation is: don't worry unnecessarily. The second rule is: profile!

Not really "premature" I do need to retrieve dynamically the param's normalized value at audio rate, applying mod and smooth.

If you GetNormalized() (without cache it, so applying From/ToNormalize functions) on 200 params for 64 voices, well, a bit of CPU will increase, uselessly.

And re-design the whole, caching this calculated (from steppy) normalized value, could introduce some problems; that's why I asked why the whole logic are with "readable" values. But I think to have edited finally the framework, so I can work with cached normalized values at any time

[Andi!]

Originally Posted by Nowhk

If you GetNormalized() (without cache it...

I "automatically" cache the parameters in OnParamChange into an e.g. mGain (and maybe other depending) variables in the format that I need in the audio processing. Why caching it additionally ?

[Nowhk]

Originally Posted by Andi!

I "automatically" cache the parameters in OnParamChange into an e.g. mGain (and maybe other depending) variables in the format that I need in the audio processing. Why caching it additionally ?

Set new values request to Param can come from Host or GUI (which is covered by OnParamChange, and you are ok), but if you have internal automation on param (such LFO->Param1->Param2), you would update all of theirs supporting variables constantly, which introduce even more confusion and knots.

Since the origin is unique, I feel better to keep the updated value from the source where it change, its more straightforward...

[Andi!]

Originally Posted by Nowhk

...but if you have internal automation on param (such LFO->Param1->Param2)...

And why are these IParams and not just internal parameters/variables ?

[Nowhk]

Originally Posted by Andi!

And why are these IParams and not just internal parameters/variables ?

Because... they are parameters They can be modulare by Host or GUI as well. Mod that go in serial/parallel with internal and external triggers... all linking are n-m.