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__