and once more a question on data structures...
how can i limit the range of a field in an array? this here doesn't seem to work:

@toxonic DS stuff : http://www.pd-tutorial.com/english/ch05s02.html maybe it will help.

@Boran-Robert thanks, but unfortunately it doesn't! i already checked that, there's not much about arrays... indeed this was the first document i read regarding DS, because it's also pubished in my native language (german). anyway, thanks for your reply.

@toxonic See this example by @Balwyn: https://forum.pdpatchrepo.info/topic/10709/getting-the-output-from-a-struct-element-i-think-i-m-getting-close

But a major drawback is that you cannot determine which field is modified by looking at the output of the structs. You can only get the pointer to the array, but also get some buggy results sometimes.

Here is another example that doesn't use array because of that: https://forum.pdpatchrepo.info/topic/10806/64-struct-sliders-no-mouse-external

@ingox yeah, but that's what i've been looking for - i didn't think of using plot for limiting the values. in this case, i don't need the index of the modified array element, because the values will triggered by a sequencer, that just iterates through the array. i store all the values at once with a combo of [array get] / [array set].
what i still find unsatisfying is, that i don't get it to work, that the values get stored in a hidden table, that saves the contents with the patch, right after i changed a value. at the moment, i use [mousestate], wich let's me store the values, just when i release the mousebutton. i'd love to get this in vanilla, but it seems that the data structures only give me click events, but not when the mousebutton is released. but ok, thats off topic now.... if someone knows a good workaround though, don't hesitate to reply! however, thank you very much!

@toxonic Not "true" vanilla I suppose...... but you can get a mouse up event with a plugin........ mouseup.zip
David.

@whale-av hey, that's quite nice! i got an error message, although it seems to work though.

UNHANDLED ERROR: extra characters after close-quote
    while executing
"pdtk_post "loaded: experimental mouse plugin
"`"
    ("uplevel" body line 17)
    invoked from within
"uplevel #0 $tclcode"
FAILED TO LOAD /home/toxonic/.local/lib/pd/extra/focused_mouse-plugin.tcl
-----------

EDIT: found the buck, there were some " ``` " signs at the end of the code.

after restarting pd (not the patch) it spits out a lot of error messages,: mouse recieve: no such object..
anyway, thanks for the idea!

@toxonic If you just need a mouse up "bang" then you can delete the other lines and so reduce the error messages...... to mouse up events only.
David.

the problem also for me with the mouse plugin is, that you always need the [mouse receive] object in your patch if you want no error message. i think the best vanilla solution for getting mouse coordinates is this https://forum.pdpatchrepo.info/topic/10854/xy-abstraction-to-get-mouse-click-and-drag-coordinates-vanilla, but there is still a lot going on just for getting the mouse coordinates. an easy way to get mouse coordinates and a resizable drag area would be a nice addition to the data structure functionality (not sure if that would be possible...). yes, in some aspects they are unsatisfying

@toxonic Yes, mouseup is not possible in vanilla.

There is this method using [r pd] and [route ping] to detect changes in the array described by @whale-av in this thread: https://forum.pdpatchrepo.info/topic/10709/getting-the-output-from-a-struct-element-i-think-i-m-getting-close/14, but it is not 100% reliable if i recall correctly. It is some kind of signalling between Pd and the GUI, but as they are processed somewhat independently, Pd does not get an event on every GUI change.

By the way, i found a method to make the mouse plugin at least work without error messages: mouse-plugin.tcl

This creates a hidden file that contains a [r mouse_receive], opens it in the background and deletes the hidden file. This way there are no error messages, because there is always a receive present. It is still unclear how to determine the correct window from the focused window code.

Usage: Put the mouse-plugin.tcl in the extra directory, restart Pd, open a patch, create a [r mouse_receive] and connect it to a [print]. You can now see mouse movements and mouse up and down events.

Maybe this can be improved if a method like "ifexist" exists.

I came up with this a few years ago, using plot and a [line] as a bang firing delay to update the array, not ideal, but an interesting vanilla option. It peters out when the [line] has completed requiring another click.
slider-line-2.pd

@ingox @Jona @whale-av @Balwyn People, you are really amazing! All these hints are very useful! in this particular case, @ingox / @whale-av 's tip regarding [receive pd] is a solution, which works pretty well and makes [mousestate] unnecessary! however, a big thanks to each of you!