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

Miller Puckette msp at ucsd.edu
Wed Jul 4 20:48:00 CEST 2012

These are good ideas, thanks.


On Wed, Jul 04, 2012 at 11:40:57AM -0700, Jonathan Wilkes wrote:
> Hi Miller,
>      I think the whole gpointer thingy forces Pd users to think about
> unnecessary details-- like scalar creation order-- just in order to use
> them, which is exactly why the #1 complaint about them is that
> nobody understands how to use them.  You've designed the rest of
> Pd to hide just the things data structures reveal.  Unfortunately
> 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.
> 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.)
> 2) Allow scalar creation by typing the name in an object box.  If I
> have [struct foo] in a subpatch template I should be able to type
> [foo] andhave it create a scalar.  If I loaded a library named "foo"
> that includes a template for [struct bar] I should be able to type
> [bar] or [foo/bar] and have the scalar create.  If it's any harder than
> that to create a scalar then the number of people who will understand
> and benefit from using data structures will never exceed the number
> of people who understand and benefit from dynamic patching (which
> is very few because it's too clunky).
> If you do these then data structures will be crystal clear:
> As an abstraction is Pd code analogous to external class in c with default widget behavior
> So too is
> A data structure template analogous to an external class in c with custom widget behavior
> ... with the added benefit that coding up such a data structure doesn't carry
> the complexity of coding a graphical external class in c.
> -Jonathan
> p.s.
> (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.
> ----- Original Message -----
> > From: Miller Puckette <msp at ucsd.edu>
> > To: João Pais <jmmmpais at googlemail.com>
> > Cc: pd-list at iem.at
> > Sent: Wednesday, July 4, 2012 12:43 PM
> > Subject: Re: [PD] [PD-announce] pd 0.43-3 released
> > 
> >(t aking this off pd-announce - sorry I didn't notice that earlier :)
> > 
> > Yep, it was indeed my original focus, and it's proved hard to make it
> > as wonderful as I keep hoping it will someday be.  Anyhow, making
> > traversal more convenient is definitely something I want to do.  BEsides
> > the ideas you mentioned, here are two others - first, being ble somehow
> > to name a pointer so somewhere else in the patch you can get what's inside
> > a pointer object - maybe somehow making it more like "v" objects.
> > 
> > Also, making pointers/data structures and "textfile" have many of the
> > same methods (and several more of them) so you can search, trim, reorder,
> > etc.
> > 
> > Much to think about!
> > 
> > cheers
> > Miller
> > On Wed, Jul 04, 2012 at 06:33:49PM +0200, João Pais wrote:
> >>  I would find it very simple if a method would allow me to find
> >>  scalar nr 2571 (I have a patch with many more) by sending the
> >>  message [traverse xxxx, bang, next 2571(, than by building a
> >>  [2571(-[until]-[next( structure. Or for example, it's impossible (?)
> >>  to erase scalers without using the mouse.
> >>  Making those simple/trivial operations less laborious to program -
> >>  i.e., incorporate them into [pointer] - could be a good way of
> >>  making data structures more accessible. which was anyway, the
> >>  original drive to create Pd, as I read in your paper (right?).
> >> 
> >>  or, what was meant with "unnecessary complexity"?
> >> 
> >> 
> >>  >Yeah... I'm still trying to figure out how to make data structures 
> > less
> >>  >clunky without adding unnecessary complexity... I'm planning to go 
> > back
> >>  >and look at that again.
> >> 
> >> 
> > 
> > _______________________________________________
> > Pd-list at iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > http://lists.puredata.info/listinfo/pd-list
> >

More information about the Pd-list mailing list