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... talk about convergant evolution. at some point i will probably attempt a merge with rrradical, but i havnt used rrradical too much, so im not sure our two metaphores are 100% identical. plus, with the way i think pd handles abstractions, there is actually no more overhead to use both rrad objects and bitvit objects in the same song file, since even though theyd be using redundant state saving objects, the code is replicated in every instance of the same abstraction anyhow. so maybe the best solution is for me to just write a memento->bv.state conduit...
I agree it's less than slick, but on the other hand, major applications like Word work the same way. You first navigate to a file you intend to work on, then you change that file.
right, but in word your data (the text of the letter) and the metadata (font info, etc) are in the same file, whereas a "song" in bitvit (and i suspect rrradical) consists of a .pd file which is the "data", the connections if bitvit objects and such, and a couple of other .txt pool files, which is the metadata. 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. i've contemplated using tot to overload the file->open menu to load it through my abstraction, unless you can think of a smarter way to intercept the open action...
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 :)
bis spater. -j