hey all, on more on data structures....
i've built an xy pad which workd fine in a valu range of 0 - 100 for x and y, but for reasons of applicability and simplicity i'd like to get it to work in a range of 0 -1 if possible. after i brought the patch into that range, it's no more possible to drag the drag-pointer with the mouse. can somone explain that behaviour? or maybe i miss something? thanks in advance!
here's th patch: xy.zip

EDIT: here's the working patch for the range of 0 - 100.
xy-working.zip

just another question to the data structure wizards here: i still don't really know, why i need a kind of "guiding" polygon (layered under the blue square), but somhow it wouldn't work properly without it (could only drag on the upper left corner of the square). can someone explain, why? please...

@toxonic Is it possible that you are using @Balwyn's xy-patch from https://forum.pdpatchrepo.info/topic/10703/xy-pad-using-only-the-events-from-a-struct as a model? Anyhow, in the answer of @Jona you can find the link to Chris McCormick's s-abstractions which contain the s-controlsurface, which is a very simple and straight forward xy-pad.

It is that data structures get an invisible dragging area of 10 or 12 pixels squared. This is not documented and i don't remember the exact circumstances how the area is created. But the dragging area is unfortunately independent from the displayed form in size, so a bigger form can not be dragged at any point. Hope that helps a little bit.

@ingox said:

@toxonic Is it possible that you are using @Balwyn's xy-patch .

Not Guilty

@toxonic just multiplying the outputs by 0.01 gives the same result

@toxonic You may get some insight into using the hotspot without a pointer with this offering I uploaded a few years ago,
https://forum.pdpatchrepo.info/uploads/files/1498974324729-xydrag.zip
The template is a little confronting but shows that by using just one xy pair (px and py) multiple nodes can be created using scaling and constraining (eg px(-100:100)(20:20) py(-100:100)(-20:-20)).
the x and y output from the grid is interpreted as greater or smaller than the previous which activates a plus or minus counter for the output values

oh, great - thanks for all the replies!
@ingox

Is it possible that you are using @Balwyn's xy-patch

no, not this patch, but yeah, i was inspired by another patch i found here somewhere in the forum... don't remembr exactly which one, but this got me started - i'm still trying to get into data structures, which is quite hard sometimes, so it's really good to have some patches to get started with...

It is that data structures get an invisible dragging area of 10 or 12 pixels squared. This is not documented and i don't remember the exact circumstances how the area is created. But the dragging area is unfortunately independent from the displayed form in size, so a bigger form can not be dragged at any point. Hope that helps a little bit.

yeah, i was afraid, this could be the answer!

@Balwyn said:

@toxonic just multiplying the outputs by 0.01 gives the same result

yes, correct - it's not a big deal to convert the output into any range, but i just hoped to keep things simple....

@Balwyn said:

@toxonic You may get some insight into using the hotspot without a pointer with this offering I uploaded a few years ago,
https://forum.pdpatchrepo.info/uploads/files/1498974324729-xydrag.zip
The template is a little confronting but shows that by using just one xy pair (px and py) multiple nodes can be created using scaling and constraining (eg px(-100:100)(20:20) py(-100:100)(-20:-20)).
the x and y output from the grid is interpreted as greater or smaller than the previous which activates a plus or minus counter for the output values

oh, sweet jesus, this is a huge template within the [pd template] patch.... i have to go to work now, but i'll try to figure it out, when i'm at home again!

thank you all for your answers, great forum!

@toxonic I wasn't aware that s-controlsurface uses a metro.

Anyhow, i made this modification, which is really simple and doesn't need an additional polygon to get dragged: s-controlsurface-mod.pd

@ingox man, that's such a clean patch and looks so simple... you are skilled in data structures.
can you give me a hint, what exactly happens with these attributes for the polygon points like this here:
y0(0:240)(10:250)
i know, it has something to do with keeping them within boundaries, but why are there two expressions in parentheses after each x and y coordinate? and why are they called x0 and y0? did i get it right, that "x" and "y" are kind of offset variables for horizontal and vertical grid of the template itself? at the moment, all i do is trial and error to figure out that stuff. is there a kind of comprehensible tutorial on data structures in the web? thanks for the the help!

Ah, i see now that your original patch can be scaled and therefor needs the additional polygon in the center to at least get a dragging area in the center. This is not possible with my previous patch

@toxonic Same here. The coordinates stuff is not documented to my knowledge. It is really some magical trickery.

So there is a polygon defined by four points. Each point has a x and a y coordinate, so eight entries. Now, the coordinates are seemingly the same for each point, x0 and y0.

But now the parentheses come into play: Instead of actually using the given coordinates x0 and y0, Pd arranges each point relative to the value range given in parenthesis:

The first x0 can move between 0 and 240 on the x axis and between 0 and 240 on the y axis. The second x0 can move between 0 and 240 on the x axis and is therefor placed at the same height as the first one.

But the second one can be moved between 10 and 250 on the y axis and is therefor placed below the first one (counting from top on the y axis, if i recall correctly).

This is some crazy stuff and i maybe somewhat kinda figured this out today, i was always baffled by this. Maybe @Balwyn has some deeper insights, i know only about it from his patches (and Chris McCormick's in this case). I hope that i didn't confuse x and y somewhere...

@toxonic here is a tutorial: https://puredata.info/community/conventions/convention04/lectures/tk-barknecht/tut.tgz/view
and in this thread are some links related to data structures: https://forum.pdpatchrepo.info/topic/10871/learning-data-structures

@ingox and @Jona : great mates, you made my day! hard to find stuff regarding pd data structures by a simple google search... i had a look into "loadbang" by Johannes Kreidler to get started.... probably not at least, because it's also available in german language, what makes it a bit more comprehensible for me. but unfortunately the explanations on data structures are also just rudimentary... thank you much for the hints and links!

@ingox said:

Ah, i see now that your original patch can be scaled and therefor needs the additional polygon in the center to at least get a dragging area in the center. This is not possible with my previous patch

well, you can't resize the patch on the fly, but if i got your explanations right, you could use arguments for the attributes in the parentheses, something like x0(0:$2)($1:$3) for example? too bad, that you can't use simple calculations like x0(0:$2)($1:$2+$1)... :-/

@toxonic Yes, it should also be possible to use data structure variables. But unfortunately, when the polygon gets bigger, you can not drag it everywhere anymore.

So the trick only works because the square has the size of the invisible dragging area. Unfortunately the dragging area always has the same size, so also scaling via GOP setting does not work.

I would always just use xy and add a visual form independently. It also has the benefit that you don't even have to click on the visual form

@ingox unfortunately it also baffles me, I struggle along trial and error fashion until it works following the help in "/doc/4.data.structures/09.scaling.pd" which is not really helpful.
You can scale the pad using dynamic patching
here is your controlsurface-mod.pd with scaling
pad.pd

Edit: No it does not work properly but I'm sure it can - working on it

@toxonic Very late to this...... and probably not understanding.
I have here......... zoom.pd added a [zoom] to the canvas [pd tracelist] that displays the numerous data structures of the tracelist in \pd-0.50-0\doc\4.data.structures/14.particletracer.pd
It just uses donecanvasdialog to set the x and y units per pixel........ zooming the canvas.
All the datastructures are then accessible with the mouse with much greater accuracy.
No idea whether that is what you are looking for though....... much too simple..... so probably not!
David.

@Balwyn So i used this idea and gave it another try: pad.pd. This seems to work fine.

Well, to make the boundaries go from -5 was not such a good idea, because as an abstraction, the square can not be grabbed outside the border... But as a demonstration it hopefully works

@ingox just brilliant!
A beautifully rendered patch that makes my patch look awkward, you have a real knack of simplifying the difficult stuff and solving too

Here now within the boundaries and with values from zero to max: pad.pd

Or from zero to max minus one, if this is more convenient: pad.pd

Just found another (video) tutorial. Not sure if there is anything new, but I think it is well explained: https://media.ccc.de/v/lac2018-26-understanding_and_being_creative_with_pure_data_s_data_structures#t=6984

@ingox said:

.... now the parentheses come into play: Instead of actually using the given coordinates x0 and y0, Pd arranges each point relative to the value range given in parenthesis:

The first x0 can move between 0 and 240 on the x axis and between 0 and 240 on the y axis. The second x0 can move between 0 and 240 on the x axis and is therefor placed at the same height as the first one.

But the second one can be moved between 10 and 250 on the y axis and is therefor placed below the first one (counting from top on the y axis, if i recall correctly).
.....

hey again! i'm still having problems to understand, how these boundaris exactly work. let's have a look at your example:

the first pair of coordinates seem clear so far. the second pair describes the point below the first one, if i got you correctly. so the x0 variable can move between 0-240 on x-axis and 10-250 on y axis, which is 10 point below the first one.
BUT... why do the boundaries of the y0-variable differ from those of x0? they do describe the same vector, so i presumed, the'd also need to be bound to (0:240)(10:250). the next coordinate pairs are equally obscure to me.... let's look at the third pair, which i guess, is the point to th right from the second one. why is x0 bound between 0 an 240 on the x-axis? shouldn't it be bound to (10:250), as it should have a 10 pixel offset to the other points? sorry for my silly questions, but this is really confusing to me...