----- Original Message -----
From: João Pais jmmmpais@googlemail.com To: Miller Puckette msp@ucsd.edu; Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@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:
- 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.
- 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