6 bools in single preset parameter

[R&R]

In my struggle with huge bank (edit: txt files) loading times, schematic size, memory usage and other challenges...

This one gave me a laugh. There's probably some nifty bitwise operation or other method of storing more in a float But here is a fugly, yet straightforward way of using string to store 6 bools in a single preset parameter. Basically bitflipping with a parsed string.

I guess one should be able to store values between 1-8 in the six decimal positions as well... for selectors (other than just bool). Just change the switches to a knobs or sliders outputting an integer 1-8 instead.

[Tepeix]

Interesting and inventive, but i'm really not sure that this will do an optimization.
Some variables is really really low memory, and when your plugin have to load, it will maybe do more tick and operation to retrieve the different value..
Consider a classic delay, or maybe buffer, you have so much more memory inside that you will need a lot of parameter to compete with this;
(even if i don't know if they load in the same way, but green is not real time sample rate)
Also, i don't know how in detail the preset works..

In fact, normally when the user doesn't change any parameter, the green or preset part will not slow anything,
except if graphic are refreshed, but did you encounter some slowdown when changing parameter or loading the plugin ?
Sometime i get some, but generally it's when i try to do a lot of calculation on large array..

Meanwhile even if i'm doubt this is an optimization, i tried to see if we could pack some boolean in a variable and come to this. Some 2^ number are added to a float, then divide to get range 0 to 1, then re multiply, then int to hex and hex to binary to finally extract the bit from text... Yep... They might be better way..

[R&R]

Meanwhile even if i'm doubt this is an optimization, i tried to see if we could pack some boolean in a variable and come to this. Some 2^ number are added to a float, then divide to get range 0 to 1, then re multiply, then int to hex and hex to binary to finally extract the bit from text... Yep... They might be better way..

Hey! That looks interesting Tepeix, gonna take a closer look to see if I understand... I love those math approaches since i'm a dummy at coming up with math solutions

Interesting and inventive, but i'm really not sure that this will do an optimization.
Some variables is really really low memory, and when your plugin have to load, it will maybe do more tick and operation to retrieve the different value..

Haven't tried my own solution yet on large scale

Yes and no... The thought is rather that reducing amount of parameters inside any "preset-bank.txt" should shorten loading of text-file time by atleast half. I'm at around 3000-3500 parameter per patch right now... That's about 240000 float values that has to be read from a flat file format
So the optimization isn't related to performance in that sense, when parameters are already in memory.

It might also reduce the size of the FS project by a tiny amount. For me it would maybe 100kb or more, since I can get rid of hundreds of param-prims and some surrounding green prims.

Whether my solution will make switching between presets any faster I'm less optimistic, since FS is very fast at what it does once everything is in memory...

[tulamide]

You both have interesting approaches, and of course an exponent to the power of 2 is the most intuitive. However, you both forget, that a 32-bit float is incapable of representing every possible value. By converting back and forth, small errors might occur. In other words, I would not advise to rely on this.

Of course, just setting bits of an integer and then saving the integer would be possible, and one could use the string preset for it. This has another advantage. Ruby does not just know one number system. You can work with decimal, binary, hex, oct and more.

But how do I display a binary number? Using to_str with the new base in round brackets. For example
3.to_str(2)
will display
11
It is now a binary string (base 2) and as a string it can be saved as such to the preset. When you load the preset, you have two possible ways to continue with the number. Either bitstring.to_i(2), which will convert it back to a decimal integer and result in 3, or by using the same approach as R&R and splitting the str. But careful! A binary string has its lowest bit on the far right and its highest on the far left (a behavior that can be changed, google little endian and big endian), but by default it is like that.

Code: Select all

a = 5.to_s(2) ## results in "101"
b = a.split(//).map { |c| c.to_i} ## results in [1, 0, 1]

You now have an array with the lowest bit at index 2 and the highest at index 0. split is a method that takes an argument (a regexp), but if you use it as shown in the example split(//) it simply creates an array with each char separated ["1", "0", "1"]. The method 'map' then converts each array entry into an integer that you could use to feed your switches or whatever else you need it for.

[Spogg]

In my struggle with huge bank (edit: txt files) loading times ...

Is this in the FS schematic view? Is it much faster in the exported VST?

I ask this because I recently found out that green performance in the FS editor gets slower as the schematic grows in size, which makes knobs “sticky” and displays jumpy, and this also affects preset and bank save and load times. You can also get stream glitches sometimes if you move a knob.

If you do CTRL-HOME the Navigator and Toolbox go away and no longer take loads of time to re-draw. To get back to normal just do CTRL-HOME again.

[R&R]

Thanks for the feedback Tulamide!

It is now a binary string (base 2) and as a string it can be saved as such to the preset.

Do you mean with a custom file reader/saver or? Since FS default preset system only deals with float 0 to 1.0... or have I missed something fundamental here?
Admit I haven't messed with these things until now when it's causing some trouble in regards to loading time of large text-file

But careful! A binary string has its lowest bit on the far right and its highest on the far left (a behavior that can be changed, google little endian and big endian), but by default it is like that.

You now have an array with the lowest bit at index 2 and the highest at index 0. split is a method that takes an argument (a regexp), but if you use it as shown in the example split(//) it simply creates an array with each char separated ["1", "0", "1"]. The method 'map' then converts each array entry into an integer that you could use to feed your switches or whatever else you need it for.

I really like the idea of working with regex. Also flattening array into integer is a nice method indeed.

I did experience the precision issue with float, that's why I ended up with the crudest solution possible as first draft
I'm uncertain in what way (probably a few) my crude solution posted here could fail, since it forces integer no matter of unreliable, dubious precision of float, either read by, or outputted by the param-prim.
That being said... if failure can be provoked without altering the solution it would be nice to see... to avoid it

[R&R]

Is this in the FS schematic view? Is it much faster in the exported VST?

I ask this because I recently found out that green performance in the FS editor gets slower as the schematic grows in size, which makes knobs “sticky” and displays jumpy, and this also affects preset and bank save and load times. You can also get stream glitches sometimes if you move a knob.

If you do CTRL-HOME the Navigator and Toolbox go away and no longer take loads of time to re-draw. To get back to normal just do CTRL-HOME again.

In this particular case it's the insane loading time of preset-bank.txt files, both in editor and as plugin/standalone i'm trying to solve, mostly

I do remember you mentioning that... and try to have that in the back of my mind when encountering similar glitches

I still edit my plugin using the older FS version, but it was a while ago since I even tried demo:ing my plugin with sound using FS 3.06/3.08.
Feels like only FS4 can handle my plugin properly. I've pushed the schematic to far

It pushes up to 20% cpu on single note, and only works with large buffer size/high latency.
And for example simple thing (some selector switching) turning off the scope makes the sound die... etc etc etc.

In FS4 it works flawlessly however

[R&R]

And for example simple thing (some selector switching) turning off the scope makes the sound die... etc etc etc.

I know exacly what junction and selector that's causing this, and that's the useful thing about older FS. If it can be fixed in older FS I know it'll work 100% in FS4.
But it's not really any connection/selectors at this point it seems, but the spike when reloading schematic that tips FS3.08 over the edge and crashes. I see it with others schematics as well.

Old FS 32-bit exports have very slow performance compared to FS4 exports, even when 32-bit. Must be significant changes to the engine...

[tulamide]

Do you mean with a custom file reader/saver or? Since FS default preset system only deals with float 0 to 1.0... or have I missed something fundamental here?
Admit I haven't messed with these things until now when it's causing some trouble in regards to loading time of large text-file

Yes, you miss something fundamental

PresetString.PNG (2.72 KiB) Viewed 20042 times

Regarding float precision, I think this article will help you understanding the issue, and why using 8 digits for fractions already becomes imprecise.
https://blog.demofox.org/2017/11/21/floating-point-precision/

[R&R]

OMG LOL

I've never needed it until now... but still, I must have flipped past it 3 million+ times by now

Yes, you miss something fundamental

Correct! "miss" is the right word, not missed. Definately a lack of brain activity behind the keyboard in front of me

Well then my MacGyver ideas can happily be thrown in the trash this time...
If I can have strings, the sky is the limit... HEX or straight of using any number of letters as the base. Splendid!

Regarding float precision, I think this article will help you understanding the issue, and why using 8 digits for fractions already becomes imprecise.
https://blog.demofox.org/2017/11/21/flo ... precision/

Certainly a good read for me... These things never seem to stick for any period of time in my peanut brain