[PD] Abstraction [define]

Miller Puckette mpuckett at imusic1.ucsd.edu
Fri Dec 15 18:16:07 CET 2006


I've been thinking about some other ways to do that (also would like to
figure out how to bundle externs, files for 'qlist', etc in a single
gesture) but there's something about this particular idea I like...

(OK here are some others:

2.  Have a "bundle" file type that causes Pd actually to build a
directory for a patch to run in complete with any other files needed

3.  fix file reading so that the Pd file format can pre-define nonexistent
file pathnames that "binbuf_read" and "sys_load_lib", etc. would check
for and pretend were there

4.  write a general state-saving mechanism of some sort

)

Anyway, there's something elegant about the "pddefine" mechanism - if I
could just generalize it to cover at least some of the other situations
I'd do it right away :)

thanks
Miller

On Thu, Dec 14, 2006 at 10:29:53PM -0700, Luke Iannini (pd) wrote:
> I just thought I'd propose an idea I had driving home : ):
> 
> As a supplement to the subpatcher functionality, what about having a
> [pddefine] object that took a name as its argument, and a patch built
> inside would then be callable within the parent patch patch, acting
> functionally equivalent to an abstraction (i.e. arguments, etc).
> 
> The advantage of this would to simplify distribution of pd-patches
> that would like to use abstractions, but don't want to have to include
> 15 files for one program.  It would also be great for "1-off"
> abstractions that aren't usable elsewhere, but are needed multiple
> times in the same patch.
> 
> Anyhow, I can't write it, so I guess it's just an idea for able devs
> to consider.
> 
> Luke
> 
> _______________________________________________
> 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