SynthMakerbootsy ·
finally the proof, that 0.5 ain't not equal 0.5 😉 :
If you change in the properties of the knob the Min value to zero then everything is fine.
weird: float does not equals
From the original SynthMaker forum (2004–2014), with its members’ names and dates.
TomC ·
bootsy wrote: finally the proof, that 0.5 ain't not equal 0.5 😉 :
If you change in the properties of the knob the Min value to zero then everything is fine.
Funny.
When you replace the float primitives with string primitives it works.
Tom
TomC ·
Oh, and while we're at it, in the same schematic (0.5 > 0.5) is true as well.
Tom
oddson ·
If you connect the output from the knob to the other float and then disconnect it will start working properly.
I wonder if it's some kind of rounding problem... one or the other of the 0.5 values is actually a rounded representation of a float value near one half. 😕
I usually use inequalities for floats because of this very issue.
oddson ·
oddson wrote: I wonder if it's some kind of rounding problem... one or the other of the 0.5 values is actually a rounded representation of a float value near one half. 😕
I think this shows it is... the value coming off the control is not exactly 1/2 for some reason.
Acrobat ·
oddson wrote: I think this shows it is... the value coming off the control is not exactly 1/2 for some reason.
Yes I came across those strange behaviours sometimes. My explanation was just that the Float primitive does not tell all the truth about the values carried around, but its in & out work good, can I say this? 😇
kirkagur ·
I have this problem too...and I think that it must be something with the trigger that don't pass thru .
MichaelBenjamin ·
in meantime as a workaround, for user control panel input or midi cc, use quantized values. i think a step size of 0.01 is sufficient for both gui and midi cc control, so this weird auto truncation display problem wont occur.
infuzion ·
SM1.1.3 will show the "actual" values for a few more decimal points. to So, if you type in "0.01" into a Float, you will actually see "0.0099999998". Malc via email wrote: The problem we had was that some people were getting confused because they were doing some float arithmetic and the values didn't seem to add up. Aliasant in particular reported such an issue. The reason for the confusion was that SM was displaying let's say 0.01 when in fact it was using 0.0099999998 in the calculation.
There's no perfect solution here but we thought it would be better if it at least showed what was happening behind the scenes. Would you agree or would you prefer that it kept the floating point representation issues hidden?
PS. here's a link to a neat little applet that shows how the 32bit float representation works: http://www.h-schmidt.net/FloatApplet/IEEE754.html
bootsy ·
Thanks for the explanations, I assumed something like this and thanks to Oddson and Michael for the workaround tips - some will do the job in this particular situation but in general I found this pretty much annoying. I would expect precise float values in the read out...
malc ·
Indeed, and as Inf says - will be coming in 1.1.3...which incidentally I'm nicknaming "the release that is perpetually nearly ready to go". 🙂
infuzion ·
malc wrote: Indeed, and as Inf says - will be coming in 1.1.3...which incidentally I'm nicknaming "the release that is perpetually nearly ready to go".
LOL I know the feeling with the VSTi I'm working on.
bootsy ·
great news, malc!!
Wrote something here? To have a post removed or your name hidden, write to [email protected].