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__
Frank,
I'll have to get back to your comments later. But about the learn feature, you're supposed to:
- select "learn"
- move your GUI item to select it as the control that'll be bound
- then move your external controller
Is this what you did?
It's been working for me... Any errors in the console?
Cheers, David . . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .
Frank Barknecht wrote:
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.
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
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.
actually the possibility to display a dyn~ patcher is really inofficial (and practically useless) at the moment... maybe there will be a different way of debugging dynamically created objects and connections.
best greetings, Thomas
Hallo, David NG McCallum hat gesagt: // David NG McCallum wrote:
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.
But this is only half or less of the picture. True, you have things like mixer settings or controller assingments in Logic et al., that don't change often. But you also have the meat of all this, and that's a piece of music (unless you work totally in the "interactive installation" sphere). This piece of music, say a midi file or a drum pattern, will *have* to be saved independently. That's what the rrad.pattseq and even the older sseq familiy allows: save a "state" wherever you want. My intention with Memento was to design a system flexible enough to do this, too. That's why the Caretaker is a seperate patch: caretaking doesn't really belong inside a state, IMO.
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.
As I mentioned in my previous mail: with the cartaker being a seperate piece of software, so to say, it would be possible to do such auto-saving as well, this is in the hand of the memento user. But it isn't enforced.
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.
Well, I can understand you well, I guess (<sore hands crying "yes">) I may rightfully be called conservative then: I tend to avoid it, because it feels "internal", "undocumented" to Pd and not someting to be used in public. ;) Or is it, Miller? I wonder, how the internal messages interface will be in the long run.
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.
God, no! Probably I'm just Jack-challenged currently.
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. :)
Yep, that's a cool one. So you did get my mail? I had problems some weeks ago with bouncing mails written to you, that's why I became slightly silent.
ciao
Frank Barknecht _ ______footils.org__
-
David NG McCallum -
Frank Barknecht -
Thomas Grill