Hello there!

I am quite enjoying pd, and find it to be great to experiment and explore new things on, along the way however I find some ideas that I would like to try yet cannot fathom how to do so.

My current wish is find out how to create a slider/number box/knob that will change the min/max values of another slider which will then be manipulated.

The second slider is used to control the highest value that a counter will count up to before resetting, and in certain applications it must count higher than the default value I have set (100). I know how to right click on the slider and manually change the min/max values, but how can I set up another secondary slider to do such a task?

Here is the abstraction that I would like to use this on, it is very basic as I am a beginner to pd. The slider on the left counts up to the top before resetting, I would like to be able to change the max value it will count to before resetting via the use of another slider or knob.

Thank you!

http://www.pdpatchrepo.info/hurleur/metroslider.ap.pd

just send a "range" message (look at vsl-help):

| |
|pack f f|
|
|range $1 $2(
|
|vsl|

I figured this would be an appropriate thread to post this question in as I see it as sort of a continuation on this topic.

What was looking to do was create a slider, vertical or horizontal, that allows for creation arguments. This would allow for ease in creating sliders with special values such as a volume slider with a default of 0 to 1, or a slider in ms for metros or such with values of 50 to 1000 or such. If this is something that can be done in pd natively, I would love to hear how! It is something that I find to be quite useful to me.

If I create an object such as [vsl 0 10] or [vsl range 0 10] I get nothing different than if I were to just create [vsl]. Upon going into the properties editor I still see that the values are default from 0 to 127.

So, I went ahead and created my own abstraction that uses;

[init $1 $2]
|
[pack f f]
|
[range $1 $2(
|
[vsl]

This is in the abstraction with the graph-on-parent set to closely hug the [vsl] so that it looks much like a regular slider. This all seemed good and effective until I tried to create another slider using this abstraction with [vsl 0 100]. This worked fine and made the slider with the correct parameters, however, it stretched the patch's size to fit the new 'name' of the patch which was [vs 0 100].

Is there any way that I can avoid this? I am assuming so, because I have found that in the jmmmp library object such as the but and butt are created without having the patch box stretched to fit the new name, and in fact, they have no name in them at all. This can be checked by opening up the created object and moving the gui object out of the way.

So, can I somehow tell pd that in creating an abstraction to not add its name to the top of the patch box?
Attached is the patch in question as well as the [but] object for you to (hopefully) look at.

Thank you for any help!

http://www.pdpatchrepo.info/hurleur/vs.pd

Here is the [but] object. I couldn't find how or if you could attach two files in one post.

http://www.pdpatchrepo.info/hurleur/butt.pd

All of the stuff in the properties dialog actually get saved as creation arguments when you save the patch. Try saving a patch with just a slider, and then open the patch in a text editor. These are used for dynamically patching objects, so I imagine you could also just type them in to the object box to set them automatically as well. I'm too tired to try it right now, though.

As for the stretching to fit the name issue, in the GOP dialog there is a checkbox to "hide object name and arguments".

I tried typing the creation arguments in an object box as Maelstorm suggests, e.g.:

[hsl 111 11 22 33 0 0 sss rrr slyder -3 -9 0 12 -260097]

but the only properties that seem to be preserved are the send (sss) and receive (rrr) symbols and the label (slyder), and none of those work properly until the slider properties menu is opened and closed with OK.

I found the same thing to be true as well, emacpher. I do wonder if there is a way to tell pd to dynamically create the patch in a way that would be successful. I am quite happy with my little object that I created, and it works perfectly with using [init] to allow for creation arguments. Solving my simple oversight of the 'hide object name and arguments' was wonderful as well!