[PD-dev] an idea for Pd structure

[Frank Barknecht]

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
-- 
 Frank Barknecht                               _ ______footils.org__