Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
Sounds like everyone I wanted to meet made it to the conference, except me!
A pity. :(
As for interpolation Its hard for me to see how it would work for Audio stuff in relationship to visual stuff. in pixelTANGO all parameters (rotate, scale etc..) pass through a helper abstraction that interpolates in three different ways, (based on global send-receive) including low-pass filtering, linear and no interpolation.
What I actually I'm contemplating is not so much how to interpolate (there are various ways to do that including line~ etc.) but how to integrate interpolation into state saving. Saved states only can contain static values, that is e.g. start and end points of a movement, that is interpolated. The actual interpolation would need to happen outside of the state saving system itself. In Memento, saving state and OSC are quite coupled currently: Every state variable is also a OSC target. I'm wondering if this connection should be broken up.
What I've done with pixelTANGO is get away from what v_ was doing (a separate OSC name for each abstraction). So that a higher-level structure would have an OSC name and any sub-modules would have a set OSC structure. For example you have a layer with a translate and rotate objects (as separate abstractions). You add a single OSC abstraction with a name like /layer1 and then OSC messages like "/layer1/translate/x" get trapped by the correct abstraction. (no support for dealing with multiple translate abstractions in one chain.)
This last problem doesn't sound too good, IMO. I need support for multiple objects of the same type in one abstraction. For example the adsr normally is used several times in one synth abstraction.
I thought about explicitly including the abstraction name into Memento and not relying on the $1-argument, but I decided against this. I would always need $1 anyway to be able to differentiate between abstraction instances of the same type. Using the abstraction name for generating OSC target names would only make it harder to create name clashes, but doesn't have any advantage besides that, as far as I can see.
I also don't use global sends at all except where global access is intentional. All Originators share only one single receiver: "r SET_ALL_RRADICALS" which is sometimes handy for changing the active state of *all* used abstractions. This is the *only* non-$0 name used in Memento. Keeping a strict border between abstractions is absolutely crucial for reusability, IMO. I explain my reasoning for that encapsulation in the RRADical doc for my talk in Graz: "Strict borders. One and only one border crossing"
Ok all that was to say that its most flexible and modular to have a number of float values that have OSC names. I wonder if there would be a way to have a standard OSC namespace for a patch that all objects can be referenced via OSC something like /[patchname]/[abstraction-name]/f1 for first float. I think OSC really becomes powerful when the namespace reflects the structure of the patch, rather than being wholly generated and imagined by the user. this opens the door to extracting the function of a patch from the OSC namespace and simply being able to standardize so that patches not made to work together over OSC magically do.
This is definitely something interesting. However another design goal in Memento is: "Not everything wants to be saved." I don't want to have to save every single float number I use in an abstraction. Most of the floats are just throw-away computational results without any real meaning that would describe, what the "state" of my patch is like. To me, this reflects Miller's original approach: Only save, what is explicitly visible. [loadbang]---[2(---[...] is explicit, [f 3] is explicit, [f] isn't.
So IMO the user should be able to specify, what is part of a "state" and what is not. This is, what the [commun] objects in Memento do: make the state explicit and visible. Doing this inside Pd would for example be possible with the idea I already mentioned: OSC- or receiver-extended atoms like [float 0 /frequency] and [symbol loop.wav /sample]. Those targets then could be magically collected into an [originator] object, if needed, which also handles remote control, and saved using some [caretaker] objects of various types like [caretaker-netsend], [caretaker-textfile], [caretaker-cvs], ...
Ciao