Green Maths Gurus - Help!

[k brown]

I recently created a wavetable osc that has all the Prophet VS waves in it, that I converted to text strings so they can be used with the wavetable osc. I used a stepped knob 'ghosted' behind the wave display for selecting the waves. I've done this many times before without issue (maybe just lucky), but with this one the preset saving/loading isn't working reliably. I'm guessing that in the past I only had 30-some steps in the knob, but this has 94, and I think the issue is there just isn't enough 'resolution'(?) in the knob to have that many steps when controlling a Selector prim; it just isn't reliably setting the knob to the correct step every time when loading a preset.

After Manfred Plummer brought this to my attention when making presets for something using this, I did a test loading a preset into random slots of the PM and 7 out of eight times it works fine, then suddenly one osc will get loaded with the wrong wave (off by one step). The obvious solution is to just use a drop-down selector instead of a stepped knob, but the knob allows seeing the wave display change as one scrolls through the list (plus using a selector would mean typing-in 98 numbers with comas between each!) - I would really HATE to lose this feature!

Is there a green solution here? Would a Ruby knob be more reliable (I've never seen a Ruby knob with steps) - I've been using vector knobs for this.

Here's a project using it.

https://ln.sync.com/dl/62c9b9f70/bbjdaw ... 8815900004

[tulamide]

A little tip:
When looking for practical help, use a stripped down version of your schenatic. It was no fun navigating through an undocumented schematic of a whole synth, just to somehow find find that one module, you're talking about!

In essence, if I understood correctly, you want to click on the waveform display and drag to select a new waveform. These are some x number of waveforms and the issue is that the integer number doesn't always match? That is always the case when working with a normalized range for buttons (0 to 1 as float value). Your hidden knob does exactly that. That's not of concern, when such a knob covers, for example, 50 to 20,000 Hz. Half a Hertz off isn't bothering anyone then.

For selecting from a fixed range of options however, you want an integer-based selector (be it a knob, a slider, or a waveform display), not a normalized float one. Such a selector directly translates x or y values of the mouse position to fixed integer steps. Not very difficult to setup. But before doing it, I want a confirmation.

And next time, please, a stripped down schematic

[k brown]

You got it exactly.

I meant to put in the post that it was only osc 3 that had the wavetable selector in question. I thought at first to just attach a schematic of the osc alone, but thought anyone wanting to help would want it in the context of a synth so they could hear what was right/wrong.

So you think there's a way to way to create a knob that generates discrete integer values? I naively thought maybe putting an integer prim between the float knob and the selector prim would do the trick, but didn't help.

Thanks for having a look, and sorry for the swamp-journey!

[tulamide]

So you think there's a way to way to create a knob that generates discrete integer values? I naively thought maybe putting an integer prim between the float knob and the selector prim would do the trick, but didn't help.

But you were close! The issue is, once again, the rather low resolution of single floats. As long as you work with the synth, it's fine. But at one point you will save the normalized float value to a preset. This number can under certain circumstances now slightly change. When reading in that value the next time you use the preset, the slight change is already enough (since the number gets multiplied by, in your case, 98) to result in wrong integer values.

The solution is to not store the normalized float value, but the integer value in the preset! A float datatype can represent integers up to 16 million precisely, so there's no problem with your waveform selector. Just store the waveform selection number in a float (e.g. 13 or 79) and store this float in the preset, that's the whole trick.

Easy, once you know it, right?

[k brown]

I think you mean store it as an integer, right; storing it as a float is what it's doing now.

If so, then I would use the Preset module that's in a selector, to store the integers?

[tulamide]

No, you did not understand.
I mean storing the integer as float (presets can only store floats)!

Currently you store the normalized float value, which is a number between 0 and 1, that later, when the preset is loaded, gets multiplied by your "step" value (here 98). That is, why the result can vary (e.g. waveform 46 is selected, not the actual 45)

Instead, store the exact number of the selected waveform (so 23, not 0.2346938), and apply the exact number of the selected waveform, when the preset is loaded.

I will do an example tomorrow (it's 3 am here)

[k brown]

Is that what the preset module in the drop-down selectors do? Their input is an integer from the selector, then it's quantized into a precise float value that's stored by the preset prim?

[Spogg]

I came across this recently with one of Johan’s synths where he had 450 samples to index with the preset system.

The best way is to break into the preset module and manually set a number which is above the maximum expected value of the index. The incoming float index value (say 0 to 94) is divided by this number to get into the 0-1 range, and when the value (0-1) comes out of the preset parameter prim, it’s multiplied by this same value to get the original 94 back. The VST spec says that floats should be in the range -1 to 1 as I understand it.

Now, the important point is that this value you choose should have a reciprocal which is a rational number; one that doesn’t go on forever after the decimal point.

So 1/94 gives 0.0106382978723404… ad infinitum. This will be “rounded” by the limited precision of the float system, and when there is a large range of float index values, the lack of precision will sometimes lead to an incorrect selection.

But if you choose a value of say 100 this gives a reciprocal of exactly 0.01 so there’s no rounding effect when divided and multiplied.

Reading that back, it doesn’t seem too clear. So I’ve modified the OSC 3 wave selector “knob” preset system to demonstrate the approach. Here I used 200 for the divide and multiply, and it works on every waveform index I tried; the preset restores the correct selection. I’ve added notes in the schematic.

Cheers

Spogg

[k brown]

Really - it's that easy?! - Still, I never would have thought of it.

I'll send this fix to MP, but I'm worried he may still have a problem - I did a test of the issue by replacing the knob 'selector' with a good, old fashioned drop-down selector (which should have worked, right - same as RazorBlade), but he still had the problem; he suspects the PM, so that my be an additional issue.

Wish him luck; I really want to resolve this especially since he was the one who supplied the VS waves!

Thanks so much to you and tula for investigating this, and your module fix.

[tulamide]

But if you choose a value of say 100 this gives a reciprocal of exactly 0.01 so there’s no rounding effect when divided and multiplied.

That's a misconception! A single-precision float (the ones we have to use in Flowstone) works a little different. There's a sign bit, a mantissa and an exponent. There's a specific way of storing a number. That'S why I always say it "represents a number". A float never stores a value (e.g. 0.125). Instead it converts this number into a number of instructions for certain calculations. Those calculations are then signified by bits, and its those bits that are actually stored in a float. When accessing a number, the process is inverted. The bits are read, the calculations set up accordingly and from the combinations of the calculations the original value is restored. Since there is a limit to both, the number of bits and the base of the calculation system (which is not base 10 as in our human decimal system, but base 2, representing the on/off states of bits), the results of the reconstruction of the original value can be off for any digit length of our human decimal system.
For example, you can't store 0.01 exactly. The reconstruction will be off (see here)

So, when you multiply something that is already off, you increase the error. That you didn't experience any issues doesn't mean there aren't any. You just got away with it. But it is not reliable!

The ONLY way to store a decimal number exactly is to store it as an integer up to the float's limit of 16777216 (2^24). Any integer within this range will be represented exactly by the base 2 calculations. 257 will always be reconstructed as exactly 257.

That's why I highly recommend to store the integer, and not a normalized 0-1. The latter is only ok for a constant high stream of numbers, where an individual one doesn't add too much to the result. Like an audio stream, where people are unable to sense an amplitude difference of 0.00001 dB for one specific sample.

The VST specifications say a lot of things, that people are constantly ignoring. I wonder why it should not be ignored just when it is about precision? But I said my 2 cents. You are warned about normalized ranges for exact number steps. Do with it what you like.