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@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list