Custom source data of Rotary Slider

Hi everyone,
I am new in Juce developing so I apologize if I ask an obvious questions.

I’m trying to develop a simple oneknob “pumper” with only one slider and adsr class. I’ve a problem with the source data of the rotary slider. Now, I can handle ms value (by default).
My target is to have “musical beats” value on the slider (eg. 1/8, 1/8t, etc…)

My question is how to change the source data of the slider with my custom parameters. I can’t find a solution on the documentation, maybe I don’t know how to search it.

Hm, I’m not entirely sure what you mean by “source” and “custom parameter”, maybe you can elaborate that a bit clearer.

But for now: take a look at this example JUCE: Tutorial: Control audio levels using decibels. This would be how you change the sliders display to what ever you like. But subsequently, all you get out of the slider in your logic is a number inside a specified range but its up to you how you want to deal with it. E.g. this number could be just the denominator of your beat e.g. (1 for wholes, 2 for halfs, 4 for quarters, 8 for eights… and so on), or the actual length of the subdivision (1 for wholes, 0.5 for halfs, 0.25 for quaters…).

Sorry for my bad english. I’d like to have in my slider these values {1/16, 1/8, 1/4, 1/2, …}.
Something like this Schermata-2022-04-21-alle-18-35-23 — ImgBB
I know that real values will be float number, but I don’t know how to display fraction numbers.

Ok, perfect. Then the previously linked tutorial contains the part you are interested in.
Using the functions getTextFromValue and getValueFromText you can change how your internal float value is displayed. I’d advice you to implement the slider more semantically like a ComboBox.

  1. Create an enum with all your possible states e.g.:
enum NoteValue { whole = 1, half = 2, quarter = 3, eighth = 4, triplet = 5 };
  1. Set the sliders range to Range({ 1, 5 }) and the slider interval to 1 JUCE: Slider Class Reference. Now you should have a slider that can be set to the values 1, 2, 3, 4 and 5.
  2. Use the above mentioned setValueFromText and setTextFromValue methods to change what is displayed in the label. The tutorial should give you an idea.
  3. Adjust the looks of the slider. I’m not experienced enough to give you any advice, but it should be fairly easy to remove the darker colour from the left end to the slider-thumb using Slider::setColour and the correct ColourId.

To get the value the user selected use

NoteValue v = static_cast<NoteValue>(yourSliderObject.getValue());

And to set the value (e.g. on startup)

NoteValue v = NoteValue::quarter;

I hope I could provide you with a good perspective how to achieve what you want.

there are a lot of different ways to do that. the basic question should be: do you want there to be essentially 2 rate sliders, one for free and one for temposync, and always only have the one visible that is needed, or do you wanna make just one rate slider and it can have different ranges depending on the state of the free/sync-switch? i’d personally choose the 2-sliders option if i were you because

  1. it’s easier to code
  2. people don’t automate the free/sync switch anyway
  3. if people actually wanted to automate that switch they might enjoy it more to have control to adjust every measure’s rate individually to have a snappy transition.

reasons for putting it into just one rate-param are:

  1. less parameters. seems cleaner.
  2. maybe people enjoy having less automation lanes even if it means less control.

the reason why putting both rate-types into one knob is hard because a parameter can not really have multiple ranges. you have to hack your way into that, mainly by converting a normalized parameter in different ways and tricking the user into thinking it has a range with the valueToString-lambda. having the rate parameters seperated doesn’t force you to be so hacky and it might even have the better user-workflow, at least in my opinion. sometimes i see people hardcoding the different measures like “1/4 1/4t 1/4. 1/8…” into a huge ParameterChoice, but imo it feels much more satisfying to actually make a parameter that computes sensible values, because then you can tweak the range later more easily. i could show you the code how i did it in my plugin, but it’s a lot and i’d personally rather advice you to try it yourself because of that. it basically all comes down to experimentation with parameter initialization

Thank you! I’ll study your solutions