I've been trying to finally learn how to use data structures, with some success this time. But I'm stumbling with data retrieval, and can't seem to get it to work as expected.

My objective is to have an array with a variable number of x-y data points (append) which can be defined textually (set) and then have its coordinates queried (get). But the query always comes out 0 0 until the data point is manually moved with the mouse.

This attachment should illustrate: ds-help.pd

What am I getting wrong?

Ah, I hadn't thought of unpacking the [struct] message like that! Thanks @ingox, the next version of my [sketch] project is going to be much better because of this!

@ingox This is strange--in my patch, I'm not getting any of those useful "change" messages coming out of the [struct] objects, and I can't work out why. Is it something to do with the "float c" argument? I tried adding this and it still didn't work, though I might be getting the syntax wrong.

Here is my container for the element:

and for the array:

Out of either of the [struct] objects, the only message I get is "click (pointer) 0". Any ideas?

@LiamG Yeah, it has nothing to do with float c, that is just the color. It is because in my example i add the scalar directly (can be done with scalar message or append to the subpatch). Then you get the click and change from every single object (scalar).

But when you add scalars as elements of an array, they are kind of locked into the array and don't behave as independent scalars, meaning they don't send click or change messages. When you receive a click message it will be from the main struct and the pointer will be to this main struct, but not the individual element. Sometimes the array struct will send out some crazy event, but this is more like a bug.

So this is a big mess and in my opinion incomplete implementation or even buggy behavior and has caused some headaches to some here in the forum, but this is the reality we are dealing with

Well that's a pain. I'm guessing if I place them directly, I won't be able to read the elements' positions using [get], right?

@LiamG Yes, that is correct. But you can build your own system to store pointers in a list so you can access them by number and thereby access the scalars. In the example below i did it with [list store], but it can also be done with [list] + [list-idx].

struct-demo2.pd

Here the scalars are added to the subpatch with the append method. The [append] object outputs the pointer to the scalar whenever one is added. The pointer is then stored in a list which is send to another [list store] on the right. Here you can give a number, get the pointer from the list and get the values from the scalar.

The method above to lock y0 when moving the objects with left shift key pressed still works like before.

Also there is another method that you can find in Chris McCormick's s-abstractions s-controlsurface: https://mccormick.cx/projects/s-abstractions/. The method is to traverse the pointer to the subpatch and then use [next( so many times until you reach the desired scalar. Which you then can access.

Edit: i should add that the way Chris McCormick does it, the scalars are appended to the head of the subpatch (same as i did above). Therefore the last added scalar becomes the first in the subpatch and [next( is therefore not in the expected order. Anyhow it should be possible to implement it correctly (only traverse the pointer of the append on load and on clear or instead count elements and use inverse number), but i couldn't quite figure it out on first try, so i just recommend the above method with lists which also gives the most control in my opinion

So we still use [get], we just don't use [element] anymore to select the scalar. There i was not clear in one previous post.

As far as constrained dragging, you can do it in Purr Data fairly easily:

purr-dragger.pd

As far as constrained dragging on array elements, you can do that in Purr Data as well:

purr-dragger-array.pd

A few notes:

• the "drag" event is set on the relevant [draw] command and sends notifications to the outlet of the relevant [draw] command. This allows "per-shape" events so you can tell which shape triggered the event.
• since these draw events aren't turned on by default, you can decide which events you want to listen for-- mousedown, mouseup, mouseover, mouseout, mouseenter, mouseleave, and drag. (Scroll and touch events are possible but I haven't implemented them.)
• for the sake of sanity "x" and "y" fields don't have any automatic behavior when scalar elements are drawn using [draw array]. If you want to make associations you can declare them in a message as I do in the demo.
• [draw array] has no bounding box to select it in Edit mode. Otherwise it would try to get the bounding box for all its elements and cause dropouts for arrays of non-trivial size every time you move the mouse. To get a bbox you can nest it inside a [draw svg] which creates a viewport clipped to a rectangle you can specify.
• receiving events for ds array elements is fairly new behavior. I know there's at least one crasher lurking if you try to add fields to the [struct] for an array element with extant scalars on a canvas.

Edit: clarification

hi,

I've got a purrdata patch that uses draw-array with per-shape events. it's really great for user definded interaction.
Here's what I've got so far:

purr-ds-array-interaction.zip