I'm sure that most of us have wished for a tool like this before, so I tried my hand at patching it. My aim was to create a single object that can hold an arbitrary number of sliders, defined by the right inlet, which are all sent to output as a list.

Unfortunately, it's not perfect: there are two flaws which prevent [multisl] from functioning like a proper abstraction.

1. You can't use more than one [multisl] object at the same time. I wasn't able to get the $0's working correctly here, and I don't think that it's possible with this design. I can explain why below if anyone is interested. --edit: fixed!!
2. You can re-size [multisl] using creation arguments, but it gets ugly. PD asks if you want to save the multisl.pd file, and I don't know how to get around this one. I'm using [donecanvasdialog( to re-size the GOP window, but this trips the save query. Additionally, moving a resized [multisl] sometimes pulls the canvases apart (I don't know why!) --edit: fixed!!

These problems aside, [multisl] works well, and might be useful to someone who wants to build a sampler.

Here, [multisl] is placed behind the array, to define four (or any) number of points along it.

multisl-1.2.zip edit: v 1.2 incorporates the two fixes mentioned above.

IIRC, you can send [dirty 0< to your patch after you made modifications to avoid Pd asking if you want to save.

@dwan hi Dwan, could you please explain better how to use [dirty 0(? Thanks and take care, Gilberto

Thanks Dwan! Your tip has helped me to fix the first problem. Sending a message [dirty 0( to the pd patch itself cancels the save prompt. It's a dirty solution, but it works!

Now I'm motivated to solve the second problem, which is the problem of multiple instances. When a number is sent to the right inlet, the patch creates a new canvas (cnv) object in the GOP area. These are the sliders that you see. It works something like this:

[bang(
|
|
[obj $2 1 cnv x y z(
|
[send pd-multisl.pd]

where x,y,z are the various settings for the canvas.

But if there are two [multisl] objects open, then the create message will get sent to both of them. Usually you can use $0's in a patch to sort this kind of thing out, but I don't think it works with a PD internal message. The only way I can see it working is if I renamed the patch itself "$0-multisl.pd" and then sent the create message to that patch. But I tried this and it doesn't work.

Can anyone see a way around this, ie. a way to send an internal message to only one instance of the abstraction?

Hi LiamG, did you check the iemguts library in pd-extended ? I don't know if it's relevant to your problem but there is some stuff there you can use to manipulate canvas and $0-stuff from outside if I remember well.

Oh, this does it! [sendcanvas 1] instead of [send pd-multisl.pd] will create an object on only one instance of the abstraction. Thanks coloscope for this tip! I was using [iemguts/receivecanvas] for the mouse information, but I didn't know about these extended functions.
I'll have the finished version in a day or two.

It was just a shot in the dark, but I'm glad you've found what you need. I keep finding useful stuff in all these libs, some are just amazing.

Here she is, all dressed up and ready for the party. You can now create any number of [multisl]'s at the same time, and you can use creation arguments to resize them without complication. There are no bugs that I'm aware of--let me know if you find any though! Thank you to Dwan and Coloscope for helping me with this.

I forgot to mention earlier that the the scale of the slider is simply the number of pixels (or whatever the units that PD uses are). By default, the scale slider is 128 units long, hence the output is from 0 to 128. To change the scale, you can use the [list-math] object at the output. [list-math / 128] will scale the slider so that it outputs from 0 to 1.

@LiamG multisl-1.2.zip

Hi Liam,

Really nice job, I really like this object!

To change the scale, you can use the [list-math] object at the output. [list-math / 128] will scale the slider so that it outputs from 0 to 1.

Can I make a suggestion? Why don't you put a [route scale] after the first [inlet}, so the user can set his own scale with a message such as [scale 0 127( or [scale 5 7(. That would be a much more elegant solution in my opinion than to explain the user to add a [list-math / 128] himself. And you can even make the default case have a scale from 0 to 127 just like a regular [hsl] has. What do you think?

Best,
Gilberto