[PD-dev] an idea for Pd structure

[B. Bogart]

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 at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
>