Save as string - rounded up

tester · 9 Apr 2012

Tried with string primitive instead of float?

oddson · 9 Apr 2012

rocko wrote: I use the "save to text" module, which rounds up these numbers to "6" digits after the dot:

I'm not sure what that module is? It's not in my toolbox.

You can write numbers as text (Text Save primitive) but you can't calculate to that level of precision with floats in SynthMaker.

tester · 9 Apr 2012

I seem to have similar scaling problem here, but with editboxes. Having values like 1000.000Hz (from range +/- 22050), when rescaled to 0-1 and then rescaled back to Hz - I'm getting values like 1000.001. I don't want to change the rounding, because it's useful as it is (in certain ranges). Plus - what user would say if he gets different value than he entered?

So we are getting back to the topic, that mr Dell so did not liked: host compatibility list. I'd like to know - which hosts have no problem with presets not scaled to (0-1) range.

oddson · 9 Apr 2012

That's a separate but related issue. Both involve the limitations of single-precision floating point numbers. http://en.wikipedia.org/wiki/Single-pre ... int_format

If it is only display issue that is concerning you (as opposed to loss of precision) then you should look into the format primitive (or better yet, given its stability problems with badly structured string inputs, at my Format modules).

tester · 9 Apr 2012

It's both - display and precision. Format primitive is there and is set to round to 3 places.

I'm aware of the single-precision floating-point format limitation, but I'm curious about SM/simple solutions to that. I'm guessing, that some combination of string primitives and asm/coding could maybe help to bypass the problem?

trogluddite · 9 Apr 2012

Another part of the problem that has SM usually displays "humanised" numbers - i.e. it displays numbers as close as possible to round decimals even for those numbers without an exact binary representation. (Just as 1/3 = 0.3333333....., a fixed point decimal might convert to a binary with infinite places - so is never exactly representable). In the advanced options, there is a tick box to show floats as the actual number that the binary really represents.

So for Rocko's problem - Always be wary with text representations of numbers - you can write as many decimal places into text as you like, but once they are parsed into floats, they will always be trimmed to the CPU precision. The text output looks about right, as the precision of 32bit floats is roughly equivalent to 6.5 significant figures in decimal.

@tester - Once the limited precision has done it's work, there is no way to reverse the procedure other than knowing what the original number was. "Out-of-range" values will be a problem for VST parameters if the user wishes to control them from the host (i.e. automation, MIDI learn via host etc.) - if they are for recalling presets only, then I'm not aware (yet!) of any host that has a problem with it. Before considering saving values as text, I would carefully check that the conversion isn't doing any funny stuff like SM "decimal cleanup" to the float values - you could easily lose just as much precision this way, as by scaling the values.

tester · 9 Apr 2012

Due to specificity of my projects - I have no plans for supporting automation routines in hosts; rather internal timeline with proper precision and behaviours. Saving presets with original/custom values (as they are entered into editboxes) - is for me more preferable, because preset txt file can be than edited manually by user. Besides - preset data can be then easily used for presentations.

So if hosts have no problem with other than (0-1) values in situations when the preset is only used by plugin, then I'm very satisfied. Thanks!

rocko · 10 Apr 2012

Hi,

So according to trogluddite:

So for Rocko's problem - Always be wary with text representations of numbers - you can write as many decimal places into text as you like, but once they are parsed into floats, they will always be trimmed to the CPU precision. The text output looks about right, as the precision of 32bit floats is roughly equivalent to 6.5 significant figures in decimal.

I can not expect a higher the ~6.5 significant figuers in "green" coding?

Thanks, Rocko

trogluddite · 10 Apr 2012

That's right - the only place where SM allows extra precision is a handful of "Double" (i.e. 64bit) stream primitives - they can be handy to give iterative maths some extra accuracy (e.g. precise sample counters etc.), but without "extra-precision" green parts, there's no way to pass 64bit values as parameters.