Adding Preset to Edit Box

[Perfect Human Interface]

I'm using the stock preset manager with the preset parameter primitive.

As per the manual: "The VST preset parameter system requires values to be floats in the range 0 to 1 . You must
make sure that you transform any values you want to store into this range before passing them to the
VST Parameter component. "

[billv]

As per the manual: "The VST preset parameter system requires values to be floats in the range 0 to 1

Yeh, your right,thanks for pointing that out, although I don't understand it.
I've never had an issue pushing int's through. I always get int's back.
I've built dozens of synths with heaps of selectors for example, and they always have ints.
And this is using stock PM and VST Para prim.
I just don't get this 0..1 range restriction.

I'd really like to see an example of where someone pushes a int into
the VST Parameter prim using the stock PM, and can't get the same int back.
i can't re-create this error.

By all means, stay with the DSPR 0..1 thing.
Probably good reason for the restriction, but I'm not really interested in it.
I'm more interested as to why i can always get a result pushing int's through, if such a restriction exists.

[tulamide]

I'm more interested as to why i can always get a result pushing int's through, if such a restriction exists.

Because it's not a Flowstone restriction, but a VST restriction: "All parameters - the user parameters, acting directly or indirectly on that data, as automated by the host, are 32 bit floating-point numbers. They must always range from 0.0 to 1.0 inclusive, regardless of their internal or external representation." From the Vst Plug-Ins SDK Documentation. Paragraph "Processing Options"

Additionally an int can always be represented by a float, and Flowstone doesn't seem to check if the values are in the 0-1 range. So it's more of an advice than a restriction on the Flowstone side.

[billv]

more of an advice than a restriction

Ok.
It's just when they use the word "must", this implies a definite restriction.
DSPR use the same word in the manual.
Sort of all means I've been living in a 'loophole' all these years..

as automated by the host

Thought for a moment...hey, maybe that's where the grey area was.
Double checked but host still automates my selector.

I'm staying in the 'loophole" till the day i get an error.

[tulamide]

It's just when they use the word "must", this implies a definite restriction.
DSPR use the same word in the manual.

I totally agree. This held me back from using any other values than 0-1 for quite some time. And I only accidentally learned that it works with any other value as well

I think this is something development teams call an inconsistency.

[Perfect Human Interface]

I feel uncertain about not following supposed VST specification even if it does seem to work... which it does. I tried changing everything to INT and it works fine now. Hmmm.

[billv]

I feel uncertain about not following supposed VST specification even if it does seem to work... which it does. I tried changing everything to INT and it works fine now. Hmmm.

Yeh I know, its a bit disturbing...yeh ??
Bear in mind i don't know the 'technical" details..I'm just speaking from practical usage.
There's got to be a "guru" reason somewhere for all this...
Got to be a situation somewhere where ints wont work...

I'm real glad you finally got a result, but I would be more comfortable if a Guru chipped
in and clarified it a little, get some peace of mind and take away the 'illegal/outlaw" feeling

[Exo]

I feel uncertain about not following supposed VST specification even if it does seem to work... which it does. I tried changing everything to INT and it works fine now. Hmmm.

Personally I think you should always stick to the spec even if it seems to work. The VST spec in many area is not enforced and so many VST devs over the years have done stuff "wrong". A lot of hosts make special allowances for plugins that are not following the spec correctly, so this could be one of them cases. There might be hosts that are following the spec to the letter and expect 0-1 values which would break your plugin for presets and automation. Saying that it might work in all host but better to be safe, it's not a big deal to scale your values down to 0-1 before the preset primitive and then scale it back afterwards. This is done in the GUI Selector module as an example.

[Perfect Human Interface]

I agree with that Exo. Much rather be safe.

I've removed the Ruby rounding code that KG provided. Now it will save the value correctly except it's off, as if with the rounding error discussed before. My suspicion was that the Ruby code block was overwriting the value on load for some reason and it looks like that is the case. I'm not sure why, or how there could be a rounding error in the first place when I can't recreate it in the schematic in Flowstone. But I might be able to fix this with a different rounding code.

[billv]

I agree with that Exo. Much rather be safe.

i agree too. But I'm still gonna cheat, old habits die hard.