Okay, Frankie, here are some responses to your comments...
. . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .
Frank Barknecht wrote:
Regarding Settings, I have several comments (long brainstorming following):
One philosophical difference still remains: where to save a state? Your settings doesn't provide a way to select the location of the save file currently, and it automatically saves every 10 seconds, IIR. The last thing is dangerous in my opinion, because not all changes are useful to save (think undo!) and the first is inflexible: Users might want to use one patch for several pieces of music. At least I'd want that. They also might want to keep an earlier version of a piece on disk, while working on an update. Both things could be done in Settings, too, of course, but currently they require file system operations in an external software (a file system manager to copy or move files).
The way I look at this project is all I wanted to do was to essentially emulate a piece of hardware. When you walk away from your mixer and come back to it, everything is as you left it. When you save a setup in whatever studio software you use (logic, whatever), all of those settings are saved with you. There's no concern for choosing a settings file, saving a settings file, remembering what you called it and where it was saved. I find the whole concept of manually dealing with settings "files" on a user level to be really arduous and unnecessary.
I see your point about multiple setups in one file. I never actually considered that because I just don't work that way. :) But I do see your point. What I would choose as a solution to that would be to allow the user to assign numerical values to different settings setups, but these setups would all be stored in the same settings file and could be called up according to their numbers. I mean, we could even do this using symbols so that the setups could be named... Hmmm...
On top of this, though, I would have one separate setup, say Setup 0, that saves every 10 seconds or so just so that there still is a "last configuration used" that the user can go back to.
Memento requires more hand-patching than your system. Each send/receive has to be connected to commun objects and so on, whereas your daughter_map does a lot of things by just instantiating an abstraction with arguments. But you're cheating ;) with using internal messages to build things on demand. I think this in general is okay, but I have found that using this extensivly slows down patch opening, and on Linux this might lead to Pd being thrown off the JACK audio server's DSP chain. Also using auto-patching can make the readability of a patch's inner workings worse. Often is is harder to understand what a patch does and how it's done when auto-patching is used.
I wouldn't say I'm cheating. :) I'd say I'm making life easier. I hate
patching. Especially for repetitive tasks like the ones we're trying to solve. The more that can be accomplished internally with these abstractions, the better. I'm creating these abstractions so I can plop them down and just start working. Putting a functional controller in a patch shouldn't be an arduous process.
As for internal messages throwing off the DSP, I think that, once
again, this is just because I don't work that way. I don't trust Pd nearly enough to do things like open patches or call abstractions while I'm in the middle of a performance.
I agree that the autopatching makes the patches harder to read. My
autopatching is really only done to get around limitations of interfacing with Pd to get certain objects called up the way that I want them to be. I'm actually starting to replace all that with Thomas Grill's [dyn~] which is making everything so much easier and should make things more legible once the display for [dyn~] gets more functional.
But hey, aren't you happy I replaced my old
controllers-through-arguments system with a MIDI learn? I'm pretty happy with that. Thanks for the suggestion. :)
Um... okay, that's it.
David