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.
it would be much easier with vanilla, since these are vanilla features.
and that would also test part of your new guide, anyway. I think there is
a page for compilling vanilla somewhere, will search for it later.
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.
although the element being changed belongs to the array defined in another
struct...
and what will make sense when you have an array made of other arrays?
doesn't happen very often, but I do have an example in my data-s workshop.