Hi, after month of research and with the help of many, here is a vanilla multislider that supports jump on click and dragging:

multislider.pd (updated)

@emviveros's post gave the hint: A click can actually go to more than one struct, so i created rows and columns to get the click. From there the slider is set. The idea was to click on it again via click message to drag the sliders. But somehow it is not even necessary. It just does it.

Many thanks to @Balwyn, @whale-av and especially to @Jona, whose idea it was and whom i worked with on the problem from the beginning to the end.

The method still has some limitations and the patch some unresolved issues.

Anyhow, i think it works great. Enjoy and have fun with it!

This now works very well: multislider-c.pd

The grabbing areas are gone, the patch is cleaned up. The bug is solved with the virtual mouse click trick, which is fun, but requires the patch to know the filename of the outer patch. i think about a better solution.

I really like the grid trick and the way the whole thing evolved
Cheers
Balwyn

Very nice view... Works beautiful! Crazy solution for the click and drag behavior... Like it a lot!

i updated the original post. The current version is now stable even without the virtual mouse click.

The problem was, that to drag the whole plotted array, the click has to go to the invisible grabbing area of the element, which represents the variable y. In the first version, when this area was missed, the click would not grab the element and dragging wouldn't work. The virtual mouse click solved this, because it would always click at the center of the element where the grabbing area is located.

The current version doesn't need the virtual click anymore, because it moves the whole struct on click, so that the grabbing area of the element is moved to where the mouse is. After it got the click, it is moved back to the original position.

The drawback is, that it is not always accurate while dragging (the virtual click solution has the same problem). The further you click away from the center of a slider, the more inaccurate it becomes. i am still looking for a solution for this.

i also made another version, which uses pixel dragging instead of the plotted array drawing feature:

multislider-pixel.pd

Now this way it is always accurate, but because it is processed through Pd and not directly working on the data structure, it will miss some sliders if you move the mouse fast. This is the effect you also get if you use an external to get the mouse position and set the sliders from there.

multislider_r.zip
because data structures can get slow if there are too much structs in a patch, i tried to replace the rows and columns with receivecanvas from iemguts. the rows and columns are especially slow if you close the patch without clearing the data structures. so this attempt isnt vanilla anymore, but its less cpu intensive and more accurate than only with a mouse external, because you still drag the data structure array after the first click. with 320 sliders it still starts to get slow, but several instances of 64 sliders are no problem (only in theory, because there is a problem with the click message if i use multiple instances).

here is an example for the slow behaviour. if you close the patch test2 without using the close-pd button the patch with 12x 320x16(pixel) sliders will take about 30 seconds to close. the close-pd button deletes the data structures before closing the patch, then its much faster: ds_clear_test.zip

@Jona about 9 seconds on my linux system...
But this is still a problem and very unfortunate...

Also it seems i can't beat the inaccuracy. i tried it with additional plots, GOP jumps, relative x, variable polygon coordinates... still no luck...

@ingox i think these are the (sad) limits of the data structures. still nice possibilities to use them. of course it would be much nicer if there would be an easy vanilla method to get the mouse coordinates (at least for mouseclick) and a better data reallocation for data structures. i dont know about the inaccuracy, perhaps it has to do with the behaviour of the struct draggable area. of course it would be nice to solve that, but its still usable like it is. another thing that i found out about struct is that if you press alt or ctrl and click on a struct array you delete or create an element of the array, dont know if thats a bug or a feature (if i remember right @Paulinho uses this as a feature in his drag sequencer)

@Jona In this case, the inaccuracy comes from jumping back. In the patch with the 20px sliders, the next slider will always be selected after the mouse has moved 10px, which is only accurate if you actually clicked on the center.

i also made this version without any jumps (only the slider jumps in y-direction): multislider-e2-more2.pd
Here there are two plots (one is invisible, but still clickable). Both control y so the sliders will react on both. You either grab the first or the second plot depending on where you click.

The grabbing area is 12x12 pixel large, so the first goes from 0 to 12, the second from 8 to 20 (its center is at 14). Here the inaccuracy comes from the grabbing area. And because one of the plots (the top one) will get the grab over the other when they overlap, the inaccuracy is unevenly distributed.

Here a version where the struct jumps, but the jump back is disabled. It is always accurate. i also set the line width of the plot to 1 so it is visible what is going on: multislider-jump.pd

Sorry for posting in patches btw, this still is a technical issue

thanks for the explanation. in multislider-r i also removed the jumps because the width of the sliders is not bigger than the grabbing area. the jumping is only needed with slider width bigger than 12 px. alternatively you can use the other 2 methods you mentioned. still, if you click in the middle of a slider its accurate, if you click outside its not (with a 10px slider the max inaccuracy is 5 px).
i think its somewhere between a patch and a technical issue

is there a possibility to send a mouse message into a closed subpatch (a gop)? it seems that the mouse message only works in an open (sub)patch.

You're right, you can't send a mouse message into a closed subpatch. But you can open it, send a mouse message, and close it all at once.

@LiamG thanks. i tried the message (vis 1, mouse $2 $1 1 0, vis 0) but somehow it doesnt work. perhaps its a special case because i want to grab data structures with a mouse message while clicking on a gop. the idea is to use the patch as an abstraction and then its a problem if the mouse message is sent to the main patch (if there are several instances of the external in a patch), so i like to send it to a GOP called $0-patch.

another finding is that in this case iem_event as a mouse external doesnt work because depending on the creation order you whether get the mouse coordinates or you can drag the data structures. with receivecanvas it both works.

@Jona I think it's not working because a data structure will only respond if you click near its boundary. You'll have to find some way of sending a "mouse" message to the coordinates where it is already set, and then a "mouseup" to the coordinates you want (and maybe even a "motion" in between). This might be more trouble than it's worth.

i think we found a simple solution with using iem_event instead of receivecanvas

Here is a version that uses receivecanvas from iemguts. No click message is needed:

multislider-e3.pd

The receivecanvas objects (a bunch to support deep gop nesting) are created by dynamic patching, so that they would receive the click before the struct. This can possibly be done otherwise. It should also be possible to do it with iem_event.

mmslider.pd i think multislider-e3 is the best result so far. i modified it to control several parameters with several arrays. its no problem to make arrays invisible, and with recreating plot with dynamic patching it would be possible to change the visible order of the arrays.