Frank Barknecht ha scritto:
You have some error in your use of [filledpolygon]: The argument count is wrong. I replaced them both with [drawpolygon] and then the width error went away. It's strange, that Pd reacts like this to a wrong usage of [filledpolygon], though.
uh?!? however it was a luky strike! generally, pd likes to crash when i make some error with template/data-structures ;-)
- after placing the array, i use [setsize] to set num. of elements in
it. but the container doesn't grows horizontally, so it is painful have 10 points, all in the same x/y coordinate.
That's because you are using array elements that have a field "float x", so [plot] will take the x-spacing from the "node.x" value. This equals 0 after creation so all elements will be at x=0 (or rather at the point, where you start to [plot] which is not 0 in your example but 100). Attached patch shows one possible way to set the array element's x-values after creation.
right. i was thinking something like... thanks for showing me a solution :)
- it is possible to set a constraint on a specific field? (i.e.: i do
not want the x value of a point to be negative.)
Not that I know. One neat trick could be to use the [mousefilter] external to catch mouse-up events and then check all values and reset them if needed.
thanks for the trick ;) i used MouseState external, part of Cyclone/miXed (you can see it in the attached patch, how i realized non-negative x clipping, and negative y clipping.)
i was wondering about a funny thing: when you move points with mouse, the array has a linked-list behavior (moving a dot to the right, also moves the other dots on its right in the same direction). on the opposite, using [set <struct> <field>] seems to bypass that behavior and act like a normal vector (you move *a single* dot) (again look at the patch, do_clip routine, i had to increment x clipping by 2 units, to avoid that boring problem of having 2 dots on the same x/y coordinate)
why this difference?
ciao!
Federico