[PD] Abstraction [define]

[Hans-Christoph Steiner]

On Dec 15, 2006, at 5:14 PM, Frank Barknecht wrote:

> Hallo,
> Miller Puckette hat gesagt: // Miller Puckette wrote:
>
>> 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
>
> That would actually be a wonderful thing to have. Personally I don't
> care about really embedding abstractions into a patch, they can stay
> seperate files as far as I'm concerned. Any major application today
> consists of lots of different files and not just one executable, too.
>
> However with a growing number of abstractions I built and use all the
> time, it's becoming a bit hard to 1) share the patches with others and
> 2) make a kind of snapshot of a project complete with all abstractions
> used, for example to do easy backups.
>
> A "Save as bundle" would solve both problems. A bundle could just be a
> directory, optionally (t)archived into a single file (but please only
> optionally: I'd want to store bundles in a versioning system.

 From what I gather you are looking for, a libdir is almost ready for  
that.  AFAIK, the only missing piece is a mechanism to open a libdir  
like a patch.  I think this could be done in the mybundle-meta.pd  
file.  If Pd loaded that file when it opens a libdir, then you could  
add a tiny bit of code into it to load any other patch you might  
want.  Something like:

[loadbang]
|
[; pd open mypatch.pd(


>> 4.  write a general state-saving mechanism of some sort
>
> That's of course the part that's a little bit tricky. A good start IMO
> would be to include the power of something like [OSCroute] into Pd to
> easily access state variable hidden deep inside abstraction trees,
> preferably with wildcards (like: "/*/slider_[abc] 127") and to have
> a dictionary- or map-like data type to quickly store and restore
> values by the name of a key instead of having to walk through a
> list as in textfile.
>
> A further step would be some easy way to read and write the state of
> objects without having to watch their communication through senders  
> and
> receivers, but that's the hard part, because it touches philosophical
> questions like: What actually is a state? ;)

I am a big fan of the way that you have done it, Frank, using only  
existing objects.  I think to make the whole thing complete, there  
should be a set of GOP GUI objects with your state saving stuff  
inside.  Then people just use those GOP objects if they want state- 
saving.

This gives me an idea of where having the IEMGUI separate would be  
handy: if you have a set of GUIs all named the same as the IEMGUIs,  
then you could add state-saving to a patch just by changing [import  
iemgui] to [import sssadgui].  Then [hslider] would change from  
[iemgui/hsl] to [sssadgui/hsl]

.hc

------------------------------------------------------------------------

Access to computers should be unlimited and total.  - the hacker ethic