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 changed)?
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.
-Jonathan
João