Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote:
So you do it the same way as I do.
if i ever get around to releasing bitvitriol to the public you'll probably chuckle at the similarities :) i think you and i started doing almost exactly the same thing in the same way at the same time...
We're not alone. Dave McCallum is also doing stuff in this area as is Ben Bogart somehow. Actually I'm sure, everyone is using some kind of state saving and GOP. ;)
so as long as you open up the .pd file through the bitvit provided wrapper, all is well, but if the user uses the tempting "file->open" command on the pd window (which a friend of mine did) then the patch will open and freak out not knowing where to find its metadata.
This problem is not existing in RRADical. Unless a user decides to save path information inside the RRADical pool (for example the location of samples) everything is independent of the location in the filesystem.
I did it by "abstracing" out the actual "saving", which is now called "caretaking" and done by various caretakers. In fact, if you look into the current CVS I already work on a state saver which doesn't save to the filesystem at all, but can save *into* an OSC connection, that is it send the whole state to a network connection. Other caretakers like for example a CVS checkin caretaker are also possible.
The good thing about this is, that you can even save the file in another location under another name. So you can keep two working copies or even use the same patch for several pieces.
two song files sharing the same metadata? or two metadata's sharing the same file? interesting, but confusing :)
Two state files for the same Pd patch. For example I have the beginnings of a performance patch at http://footils.org/pkg/showcase.tgz which contains some samplers, drum machines and an FM synth. I can play various tracks with this by just loading another state file into the pool. It's like a sequencer where I just load another score.
Ciao
Frank Barknecht _ ______footils.org__