[PD] [PD-announce] pd 0.43-3 released

[Jonathan Wilkes]

----- Original Message -----

> From: João Pais <jmmmpais at googlemail.com>
> To: Miller Puckette <msp at ucsd.edu>; Jonathan Wilkes <jancsika at yahoo.com>
> Cc: "pd-list at iem.at" <pd-list at iem.at>
> Sent: Wednesday, July 4, 2012 7:38 PM
> Subject: Re: [PD] [PD-announce] pd 0.43-3 released
> 
>>  the user doesn'tget expressivity through data structures that would
>>  be comparable to just coding a c external, but they do get a
>>  (somewhat) comparable level of complexity.
> 
> yes, the worse is that the enigmatic (gpointer) don't mean anything for 
> someone that can't read the C code, like me. changing that format for a 
> symbolic "link" - like "structname-scalarnr" or similar, 
> user-defined - would make much more sense for users. And also, hopefully, give 
> scalars a faster way of being accessed (the traversing issue).
> 
> 
>>  Here's how to make them better:
>>  1) Make a public interface out of the trick you're already using to
>>  load pd-_float_array and pd-_float.  Users should be able to make
>>  a ds library and load that library with the same ease that they load
>>  external libraries using [declare], [import], etc. (This will also solve
>>  the problem of trying to use a data structure inside an abstraction,
>>  where on the one hand the user must use [struct $0-foo], but then
>>  that destroys any chance to save and reload state with impugnity.)
> 
> ah, that one I forgot. for my simple abstractions like [bezier] or [swatch], the 
> scalars of $0-templates are created on loadbang. but that's not very handy 
> (or possible?) when loading a score with thousands of scalars.
> 
> 
>>  2) Allow scalar creation by typing the name in an object box.  If I
> 
> A good complement to that would be scalar manipulation as well. like sending a 
> message [select scalar-1 scalar-278( to select a range of scalars, and then move 
> them (without going to the x/y fields of each one), duplicating, erasing, 
> copy/pasting, ...
> 
> 
>>  (Experimental) 3) Add a "canvas" or "glist" field to 
> [struct] as I suggested in an earlier
>>  email.  I don't think João would need to search through a linked list 
> just to find a
>>  value if he could have a canvas with the necessary objects in it that is
>>  associated with that scalar and its field values.
> 
> I didn't understood that, but it sounds very important, my name is in that 
> paragraph.

:)

When you create an abstraction, you basically save a patch that is a template
for all instances of the abstraction which you will create later.  [f $1] gets filled
in with the first arg, [symbol $2] with the second arg, and so on.

With my idea, you create a scalar that has an associated canvas (similar to
an abstraction), and that canvas has access to the field values for that scalar.

Example: let's say you have [struct foo float y symbol blah canvas bar], and
have a subpatch [pd bar] that is a template for the field "bar" which is just a
canvas.  So when you create a scalar foo, that scalar has a y variable-- which is a
float; a blah variable-- which is a symbol; and a bar variable-- which is a canvas.
Imagine a hypothetical object inside that scalar's canvas called [getmy y], and
when you bang it you get the y value associated with _this_ scalar.  Now imagine
this inside bar:

[getmy y]
|
[mtof]
|
[osc~]
|
[catch~ bus]

Now if you instantiate 16 scalars, each one of them has an associated oscillator
that gets its pitch from that scalar's y value.  In other words, each scalar also
has a canvas that holds within it the means to produce sound from the y value
that you see.

I'm just assuming here that [getmy] would work like the outlet of [struct]-- that is,
it sends out a message when the y value for that scalar is updated.  (Or alternatively
when it is banged.)

Better yet, imagine using "foo" as the template for another struct as in the following:
[struct container float x float y array z foo]

Now you can create/destroy voices in an oscbank using [setsize]!  Of course I'm
skipping over lots of details, like you'd still have to rebuild the dsp graph, and how
loadbang would or woudn't work when you instantiate a scalar with a canvas field,
etc., etc.

Hopefully some of that makes sense.

-Jonathan

> 
> João
>