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

[Frank Barknecht]

Hallo,
David NG McCallum hat gesagt: // David NG McCallum wrote:

> My abstractions collection has been updated, with all sorts of useful
> goodies.
> But the newest thing is a settings-saving system for GUI objects within
> abstractions. Features include:
> - automatic OSC control of each controller
> - MIDI learn (and 14-bit NRPN learn) for each controller
> - automatic mapping of 7-bit (or 14-bit) input to whatever range you
> want, including radio buttons
> - saving of settings in a settings file in the path of the parent patch,
> and *not* your abstractions dir
> 
> This is similar to Frank Barknecht's memento system, but a little more
> specialised, and may one day be adapted as a wrapper for his system.
> But it's its own system for now.

As expected: this is a wonderful collection, and you know I'm a fan of
it. It's definitely RRADical, memento or not. ;)

I had a problem trying out the midi learn function: somehow it
wouldn't want to learn my fader box output. I'll have to look into
it later. What I did was: Check with "Test Audio and Midi" that
midi-in is working, open !example.pd, click midi_learn, move a slider.
Then I expected, that the cc/chan display would be updated to reclect
the moved slider, but it wasn't. I also tried nrpn_learn, same result.

Regarding Settings, I have several comments (long brainstorming
following):

I think, that building a bridge between Settings and Memento would be
possible and not hard at all. Memento was designed with maximum
flexibilty in mind, i.e. it only does a limited amount of well-defined
tasks: saving, changing (through OSC or send/receives) and restoring
states. Controller mapping, input scaling and similar things, which
your Settings patches do, intentionally is not included in Memento,
but as you wrote this functionality can be realized in patches that
use the Memento system. I did a simple thing like that in the
rrad.pattseq, where I wanted the vertical radio buttons to have the
lowest value (== 0) to be at the bottom. As vradio doesn't provide a
hook to change the direction of the values, I wrapped that translation
in an abstraction around Memento's [commun] objects.  Similar mappings
could be defined to bridge your Settings with Memento and provide midi
learn or scaling.

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).

As Memento uses an extra abstraction only responible for saving and
restoring - the caretaker - users could change that abstraction to do
10-second-autosaving themselves, if they wanted to. In fact, a simple
[metro 10000] -> [save( -> [caretaker] would do the job with the
caretaker. I think this is more flexible.

Nevertheless there is one area, where prefabricated save files are
useful.  I'm thinking of the angriff drums. They come with snare,
bass, clap and hihat presets, and it is useful to be able to open such
a set in one go. This is one feature I will add to Memento in the next
update, and it will be using the svdir and lddir messages of pool to
load a single preset into a state directory. These messages are still
missing in Memento, which uses a two level deep directory hierarchy to
allow more than one substate in memory.

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.

All that's why I prefer to use internal messages only to save typing
while building a patch, but then I save the created end result as a
static patch without auto-patching.

Well, those are my unsorted comments, which are of course open to
discussion. 

ciao
-- 
 Frank Barknecht                               _ ______footils.org__