Sounds like everyone I wanted to meet made it to the conference, except me!
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. Low-pass filtering is really smooth and great for visuals. the added benifit is that small sliders (100px wide) are really choppy for rotating say over 360degrees. The interpolation smooths out the single pixel jumps/bumps and makes a nice continuous movement. Each slider just passes through the abstraction. There is a seperate abstraction that send the "smoothness" value and type to all the interpolation abstractions.
Its on by default and users just use and and say "wow, that is smooth". I guess the basic lesson is that pretty well every gem paramter can be very well interpolated. (things like video clip in and out points are not interpolated)
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.)
Right now the control bus just prepends a string to set the destination (like text) but just using OSC formatted messages for interal communication would have significant advantages.
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.
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
Interpolation is something I talked about with Cyrille at the convention and definitely something, I'd like to somehow integrate into Memento. However I haven't yet thought about a way that is "stupid" enough for general use here. How are you (intending to) doing it?
Of course it would be great if state-saving was built right into PD.
I had this crazy idea when talking with Miller about this, that it could be nice to extend the basic data type objects like "float" with a OSC-tag. Instead of [float 0] ony would write [float 0 /freq], [f 0 $1/freq] or even [f 0 $0/freq] to make that float value state-saveable and accessible through some OSC inlet or sender. Then the currently nessecary [commun] objects could go away, and [originator] and [caretaker] could become an ext-/internal.
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev