AudioParameterInt interval (to, at least, 1)?

Audio Plugins
1

Hi,

It seems that the interval of a Slider's range is not automatically set when using SliderAttachment between the Slider and an AudioParameterInt. Maybe a default setting of 1 could be used? In my case, I’m using IncDecButtons and found out I had to manually call something like incDecSlider.setRange(incDecSlider.getRange(), 1); after making the attachment to have the plus/minus buttons working as expected. Am I missing something?

Thanks!

2

It seems to me that you have perfectly understood, the slider has no reason to take into account the fact that your audioparameters is an int. For my part, I would do the same as you, using the setRange function.

3

(Note: using latest tip on develop branch)

It (the Slider) certainly would have a reason to take this into account because his NormalisableRange member would be bound to the AudioParameterInt's one upon attaching.

I have the feeling that something is missing. If you take a look at the AudioParameterFloat class, it has two constructors, the second one arbitrarily sets the interval to 0.01f (which works well with my inc/dec buttons if I change my parameter type to this one, of course). Why wouldn’t there be such a constructor for AudioParameterInt?

4

I’m not sure that’s the right answer, but it seems to me that the definition of normalisableRange is made up of float, maybe that’s the explanation

5

Seems like this may be two things causing the issue…

The construction of the NormalisableRange<float> member in AudioParameterInt uses the constructor that takes the conversion lambdas… but that constructor leaves the interval at its default (and doesn’t even provide an argument for it):

In the SliderAttachment class it checks if the interval is non-zero and uses it if so:

Does it fix your issue if you add a range.interval = 1.0f inside the constructor of AudioParameterInt?

6

Unfortunately, no. Plus, this requires to remove the const qualifier on the member.

7

Sorry, YES, it does work. I first tested with an AudioParameterChoice and modified AudioParameterInt's constructor by mistake, but well, isn’t it exactly the same concern for AudioParameterChoice after all?

Anyway, this “fix” works, but still requires to remove the const qualifier for range.

I suppose if the reasoning is correct, that could be corrected in an official way?

Thanks for your help!

1 Like
8

I’ve run into annoyances myself with that particular NormalisableRange constructor requiring non-const declarations and putting the interval on the next line down :slight_smile:

Perhaps @t0m has some input? Is the interval left out since a snapping function can be provided in that constructor?

9

Ok, I’ve been trying to get a better understanding of all this, starting from the Slider code. When a Slider is in IncDecButtons style and then plus/minus button gets clicked, incrementOrDecrement is called using normRange.interval which is natural but from there on, if interval is not set accordingly, nothing’s gonna happen.

So, again, we need to be able to set it when creating an AudioParameterInt. This has nothing to do with the NormalisableRange.snapToLegalValueFunction lambda.

And I also definitely see no reason why an AudioParameterInt couldn’t have a default interval of 1. Only makes sense IMHO.

1 Like
10

Yes, this is something we could improve.

However, simply setting range.interval = 1.0f means that we take the branch indicated in TonyAtHarrison’s post and we don’t get the value snapping behaviour we expect, so we need to do something a bit more involved.

11

@t0m what is the purpose of the conditional? It seems like a NormalisableRange<double> could be created by mapping all the attributes of the parameter range (like it’s doing with the conversion functions in the else body) and then set using Slider::setNormalisableRange()

12

I believe it was to preserve backwards compatibility in some cases.

13
2 Likes
14

Works like a charm. Thanks a lot, Tom!