in this scenario we have 16 elements with a range of 0-170. If we drag the mouse across from a node and then click the background first we get a print of "click (pointer) 0 (the initialised y position), then we will get a print output equivalent to the number of nodes with the y values of each node multiplied by 2 (why x2 ?).
Surely we must be able to capture this output

sliderbank-vanilla-debug.pd

nice step. very nice that you get the struct output of every node if you click anywhere in the gop. could it be possible to update the node possitions if you click anywhere in the gop? sadly i dont think so because you only get the actual position of the nodes. it would be even nicer if its possible to bang the struct output of pd-node if you change a node position, so that that you get the output instantly. strange that the output is multiplied by 2.

Could it be the "x units per pixel" / "y units per pixel" options in the canvas properties that nobody ever uses?

@Liamg No, that doesn't seem to do anything except prevent gop if set to zero

But here is another way to get the node values without directly clicking the background, but its probably a very bad idea
plot-to-array.pd

Ok, now I've just found [array get] has a flag to receive a pointer from structs.
But with no mouseup I'm still stuck with a delayed click.
plot-to-array-with-array-get.pd

Now I'm getting exited, 64 sliders with metro update barely registers when idle

plot-to-array-64.pd

@balwyn thats a nice finding again perhaps there is still a hidden function for jump on click if i set the metro to 10ms instead of 50ms its not much more cpu intensive. and if i hide the array its less cpu intensive. theres a strange thing about the data structures, if i move the mouse up at a certain position of the node of a slider (its hard to find) the slider goes down, so the direction is inverted. i also had a look at your drum-power drummachine. is that where your sliders come from? would writing to the arrays work better with the method you just discovered? the data structure mouse tracking seems more reliable than our attempt with iem_event because it tracks every slider and it doesnt depend on the speed of the mouse. another thing is i had the feeling a data structure array is less cpu intensive and in some way more flexible than a regular pure data array, but i dont know if i am wrong.

i was also thinking if it would help to understand how a pure data object that tracks the mouse position like the vslider, the array or iem_event from the iem_gui library works, but i assume it depends on different programming languages.

@Jona I don't think there is any hidden way to retrieve the x/y position of plot from a click (but you never know)
I came up with the slider idea a while ago when I came across "all_about_arrays.pd" [pd Data_structure_arrays] in the pd-extended help browser.
the weird inverted drag effect is something to do with vertical [drawpolygons] and the plot line I think, because it doesn't happen if they are turned off.

before i saw your discoveries i was almost sure that there is no "jump on click" for data structures. now i am almost sure again. i also didnt find any documentation about the output of a struct, that made me think there are perhaps some other funtions that are not explained at all (or work in progress). thanks for your explanation.

@Balwyn Y is inverted because 0,0 is top left..... x increasing to the right = normal....... y increasing to the bottom = not. Presumably to do with standard computer window drawing co-ordinates.
You can get the x/y position of the plot with [get].

You can drag and jump to the mouse position and click when not in edit mode. The problem is that the co-ordinates for the structure are for it's drawing screen, and the co-ordinates for the mouse are for the computer screen. I remember being able to get the window co-ordinates for the mouse (rather than screen)..... but I have forgotten (for now). Sure it can be done.

Here is one to play with..... demonstrating the problem....... It jumps and drags (edit mode on)......
jump_drag.pd
You will need cyclone/mousestate.
David.

@whale-av that makes sense. i am learning. we solved the problem with iem_event from iem_gui like i mentioned in another thread. a problem with mouse state was that it uses the coordinates of the screen and not of the pd window. after that i used a combination of canvasposition, receivecanvas and canvasobjectposition. so iem_event was the easiest solution for our purpose. somehow i like the idea to find a vanilla solution, but its not too serious. still it was interesting too find out about the structoutput and balwyn found a nice way to use it.

@Balwyn Using the ping from [r pd] gives you all the changes and mouseup..... I think. No great benefit over [metro] as most of the cpu is from the structure.
slids.pd
David.

yeah, i didnt know that there is a "ping" message. very helpful.

@whale-av that is an interesting event (ping). what is its original purpose? Its great the way it Idles to almost nothing. A problem I found is that if there are multiple instances of [slids] they are all trying to update at the same time. resulting in Pure Data stalling. I even slowed the bangs down with a modulo counter of 5 and [sel 0], which prevents the stalling but still causes a jerkiness to the mouse. I'll try a central ping and some delayed bangs next.

Ok delays didn't work as it just delayed the onslaught, but [route] works well by sending an Id from the struct click to [route] then [spigots] dispersing the cental ping bang to the correct [slids-2] (obviously the [table] at the top right would be hidden)
slids-2-ping-test.pd
slids-2.pd

@Balwyn Getting better and more useful!
The ping seems to control dataflow with the gui....... maybe to ensure audio continuity.
If you put a gui in the patch and change it's value then a stream of pings are generated. Seems to be a message from the Pd gui saying "ready, send next chunk".
s_inter.c

/* ---------------------- sending messages to the GUI ------------------ */
#define GUI_ALLOCCHUNK 8192
#define GUI_UPDATESLICE 512 /* how much we try to do in one idle period */
#define GUI_BYTESPERPING 1024 /* how much we send up per ping */

David.

@Balwyn PS....SSSSS.. P
I know it doesn't perfectly fit your criteria (Vanilla only) but a mouseup plugin might be acceptable?
It is more reliable than the old extended mousestate.
mouseup.zip
Please no laughter about the simplicity of the code!
David.

@whale-av No laughter here, I think this is amazing in its simplicity. It took me a while to work out to put the 'mouseup-plugin.tcl' in the extra folder, but now its working, I'll see what I can do with it. Are there other mouse events that can be bound in this way?
Cheers and thanks
Balwyn

@Balwyn I am on a show today..... but I am sure other mouse functions can be dealt with in the same way. I will have a go at expanding the plugin tomorrow.....
David.
PS.... sorry for the lack of explanation for the plugin. They need to be in a path that Pd opens at startup.