----- Original Message ----- > From: João Pais <[email protected]> > To: Miller Puckette <[email protected]>; Jonathan Wilkes <[email protected]> > Cc: "[email protected]" <[email protected]> > 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 > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
