Info sought: could we increase the range of values available in OSARA Params window beyond 10000 steps?

[ScottChesworth]

In a recent thread on RWP, a user has run into problems controlling the midi ctrl src 1 and 2 parameters of Synth1 (a free, accessible and highly automatable VSTI). This seems to stem from the instrument supporting 65536 values per parameter, whereas I'm lead to believe that right now, the slider control OSARA uses supports 10000 steps.
The upshot of this is that with some parameters, it's not currently possible to increment or decrement in single steps using OSARA's Parameters dialog. Synth1 is being used as an example here, but I've also seen this with other VSTI's. IN particular, it seems to be tricksy wherever a parameter is relaying CC messages.

The discussion lead me to a couple of questions whenever someone with knowledge has time to jot down their thoughts:

1. Would there be much work involved to increase the amount of values our slider can support?
2. Would that be cross platform if implemented?
3. If there's any mileage in this, is there anything I can do to be useful? :)

TIA

[jcsteh]

I'm lead to believe that right now, the slider control OSARA uses supports 10000 steps.

Unless I'm forgetting something, I think it's 1000, not 10000.

1. Would there be much work involved to increase the amount of values our slider can support?

No. To be more precise, it's not about the number of values, but rather the minimum increment/decrement of the raw value that OSARA will try. Right now, that's the range of the value divided by 1000 (normally = 0.001). Look for this line in paramsUi.cpp:
this->step = (this->max - this->min) / 1000;
If you do change that, you should probably change the multiplier below it for largeStep as well. That's the value that gets used for page up/page down.

2. Would that be cross platform if implemented?

Yes.

3. If there's any mileage in this, is there anything I can do to be useful? :)

You can try changing that value and see what happens across various plugins. :)

This change is not without risk:

1. The smaller you make that step, the larger the number of values OSARA has to try. For a parameter which has a lot of granularity, that's a good thing. For a parameter which does not (in the worst case, an on/off parameter), that's a bad thing. Instead of trying 1000 possible values to get the next useful value, we might have to try 100000 values. That could make things noticeably slower. Or not, which is why it needs testing.
2. The smaller that value, the greater the possibility of floating point accuracy errors. That basically means you might see weird results sometimes (weirder than we already see in some cases).

After you've tested this for a while yourself, I'd suggest asking a few other willing users who use OSARA daily with FX to test it too. This is not something we want to merge quickly without a few people testing it across various different plugins and configurations.

[ScottChesworth]

Got it, thanks! I'll do some experiments here, hand anything that seems promising out to a few folks and report back once I've collected some info.

[jcsteh]

I realised you might not be up for submitting a pull request yet. Once you've done your initial testing, let me know if you'd like me to submit the change as a pull request so you get automated builds, etc.

[ScottChesworth]

It's all good, I can do PR's. I'll probably build locally for Windows testing because watching it happen is still kinda fun at this point, but I don't have a Mac here at the mo, will use the automated builds for that.

[meckito]

The sliders in Osara do indeed support 1000 values, however there is an edit field next to them that supports values from 0.0000. I tried typing another zero decimal into this field however the value did not change. if it is possible to type values less than 0.0001 into this field you will probably find this to be a sufficient compromise.

[jcsteh]

Ah yes. You can type values of any precision into that field, but when the value is read, it is currently truncated to 4 decimal places, which also means it will often overwrite the higher precision number you entered.

@ScottChesworth , you may want to look at changing this line as well, which will affect the edit field:
s << fixed << setprecision(4);
If we're allowing 100000 steps, we should probably allow 5 decimal places (precision) there.

[Lo-lo78]

Hi, for example, there are plugins like js REEQ which in the filter type parameter exceeds the value of 1,000.
With the progress cursor you can select the analog filters but when you are in the editing field the value is not taken. It is as if the value were greater than 1,000
I don't know if it depends on the js from Reaper but values ​​above 1,000 are not taken.
Maybe with 10,000 it is possible to select values ​​that some plugins have.

You might think of a checkbox to turn on or off.
For example:
Increase steps to 10,000; checkbox disabled by default.
Perhaps it is better to give the possibility of having values ​​up to 1,000 by default and when needed you could optionally increase it to 10,000.
Thank you!