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...

]]>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...

]]>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.

]]>@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

]]>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 ]]>

@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!

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

]]>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! ]]>

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...

]]>and in this thread are some links related to data structures: https://forum.pdpatchrepo.info/topic/10871/learning-data-structures ]]>

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)... :-/

]]>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

]]>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

]]>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. ]]>

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

]]>A beautifully rendered patch that makes my patch look awkward, you have a real knack of simplifying the difficult stuff and solving too ]]>

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

]]>.... 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...

i completely missunderstood that....the first parentheses value pair sets a value-range, the second one is responsible for the relative positioning! and this way, it's more than easy to get a value range 0-1 for an xy pad. and more: you can set the range on the fly when you assign variables! look at this here, an xy pad where you can select between two retangles in the same subpatch with different value ranges:

xy_range_0-1.pd ]]>

....you can set the range on the fly when you assign variables!

what a pity, its seems, you can't assign variables to these values - i get a parse error!

]]>