[PD] got jump-on-click arrays working
jancsika at yahoo.com
Wed May 15 21:46:16 CEST 2013
On 05/15/2013 02:42 PM, João Pais wrote:
>> That's actually a big problem, because it means the only people
>> testing my changes are people who already know how to compile Pd on
>> their platform AND have the free time (and interest) to test the
>> changes I make. It would be much better if everyone who can run Pd
>> can also test out the changes I make.
>> I should probably tackle this problem before delving into the rest of
>> my goals. Is anyone cross-compiling for Windows using the Debian
>> packages for mingw? That would make it possible to post binaries for
>> windows and linux using a single Debian box.
> I mean I don't know how to test them. But if it's only necessary to
> compile pd, maybe that's already written somewhere? Or is there a "how
> to test new changes" page?
There is something on puredata.info about compiling Pd-extended using
either cygwin or mingw (can't remember which). It's pretty difficult if
you've never done it before.
Compiling Pd- vanilla should be easier. Still, it'd be better if I just
post a zip of the binaries for the revisions. All that would require is
a user to download, unzip, then click on the "Pd" executable, which
means any user that can double click an icon can test the changes.
>>> But I would suggest something else, in case it's somehow related:
>>> - "change" message coming out the [struct] (or [plot]?) for data
>>> structure arrays, that output the pointer and index for the element
>>> in question. Then it's possible to link user interaction with arrays
>>> as well
>> So which [struct] gets the "change" message: the one with the array
>> and [plot] drawing instruction, or the [struct] that is the template
>> for the array (i.e., the one with the "y" field that's actually being
> I would say the one with the array (and not [plot]). But I'm a surface
> user, I don't know what's happening inside.
> A con for the template struct: if this template is used also for
> individual scalars (which doesn't happen often anyway), it might get
> messy. So maybe better think of high level.
Well, there are two "parent widgets" that can receive a click-- the plot
trace itself (currently, the black line that represents the array
elements) and, if there is a drawing instruction for the scalar
elements, that particular drawing instruction like [fillepolygon]. I
guess to keep it simple the scalar element's [struct] should always
receive the notification-- even if it doesn't have a drawing
instruction, it's "y" field is the one getting changed. The [struct]
containing the array definition should only receive a notification for
things like adding or deleting elements with the mouse-- that is, for
manipulations that change the structure of the array itself. (Although
even there it would be nice for the scalar element's [struct] to receive
a message that one of its scalars died.) Complicated stuff.
More information about the Pd-list