[PD] Re: [PD-announce] mccallum_abstractions updated

[David NG McCallum]

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