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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
