And I'd like it to do the opposite direction, so that if the slider is above 4.414 the number would increase up to the limit, (on this second example 2.070)

Once it hits the limit stays at that value until. I press stop and it resets.

I've been having trouble wrapping my head around how to start with this.

1. what range has the GUI element and what does this represent? aha.

2. what numbers you want to get of it in the end and what do they represent? so so.

3. now if you dont get the conversion to work by rule of three kind of equations, the chance is high that it is a combination of more than one times rule of three.

4. and when you notice that "playspeed" has the habit to work differently below 0. than above 0., try to do this conversion using 0.-2. first, and not with the values currently required for a specific app.

i could tell you something about your specific patch, too, but i dont understand it. (is there no [slide] object for pd?)

however, in case you are doing somethign with picth modulation it is in most (yet not in all) situations more useful to do what you want to do on the linear layer, i.e. -> ftom -> myalgorithm -> mtof ->

I'd absolutely agree with this. Program logic should be program logic. GUIs should be for input or display. GUIs should not be performing program logic!

For that matter, sliders' min/max limits don't apply to values coming in:

The slider has set a limit max = 127. I sent in the number 150, and the slider sent out the number... 150. Not clipped to 127.

So you cannot use the GUI to enforce numeric limits at all. That is, the title of this thread is already leading in the wrong direction. A slider having a limit is irrelevant to what you're trying to do.

It seems like you're looking for an increment/decrement behavior that stops once it reaches a certain value (and then maybe triggers a different increment/decrement -- though this is unclear in your description because you say both "and change direction" and "once it hits the limit stays at that value until I press stop").

So, first, increment and decrement. You have the right idea with the float box. You don't need both a [+] and a [-] box because you can set the second operand: you can [+ 0.01] or [+ -0.01] using the same object.

Then, you need something that will decide whether the number is in range or out of range, i.e., you need numeric comparisons. I like [moses] for this but you could also use [>], [<] if you wanted.

So the way I would design "increment or decrement, and stop when the value goes out of range" might be like this.

Both buttons set the same initial value and start the metronome. The third outlet of the [t b b b] objects sets the up or down direction. Remember [t] outputs right to left, so the order is: 1/ set direction, 2/ set counter initial value, 3/ run the [metro].

At the top right is the "stop" signal (triggered by a too-low or too-high value). If you wanted to trigger some other action, you could put that here.

hjh

PS (edit) Actually the initializer could have slightly fewer crossing wires by splitting the [t] objects:

@ddw_music I am not certain but maybe [line] is more efficient than [metro] as in my post above...... but it probably doesn't matter for such a simple application.

I guess it depends whether the specific increment is important or not. If the increment isn't important (but the endpoints and time are), then yes, use [line]. If the important feature is that the increment be exactly +/-0.01, then I'd spell out the specific addition. (Sure, you can calculate the endpoints, time, and output interval to get the exact increment more or less, maybe some floating point rounding error though.)

But beyond that: a counter with a stop limit is an extremely common pattern of objects, IMO part of basic literacy for using Pd or Max. Yet somehow this is seldom taught as a foundational pattern (so, users often stumble over it -- as did I, at first). So I think it's worth illustrating, even if it's slightly less efficient than [line].

Yes the slider GUI does not impose limits, but is useful for display purposes. But changing that programmatically usually just adds confusion for the observer.

Useful for display, definitely. But, I see in SuperCollider as well, often users want GUIs to do actual work: flow of control, or sometimes even calculation (in SC, GUI action functions can be complex). IMO that's usually a mistake. Specifically here, the way the question is worded makes it sound like OP expects the slider to determine when the limit has been reached. I thought it was worth discouraging that expectation.

hjh