[PD] Announcing "RRADical Pd"

[B. Bogart]

Hey Frank,

> I don't see why they couldn't be compatible. It's seems to be just a
> matter of coordination.

I agree, what you did with using my OSC routes (in and out) is what I
was hoping to be able to do. This could be a good way for approching
the design for RRADical. I started making a new object for v_ that
uses the internal OSC messages to control other GOPs. Problem is that
I did not put OSC directly in this thing, because the Gops with it is
controlling are the ones that send the OSC commands. It would be
redundant (and probably problematic) to have both sending OSC
commands that end up doing the same thing. Because v_fade does
not have OSC sending commands (it does have OSC receiving) then
the state could not be saved using this method...

Any ideas for a solution? I can see how a "meta-controller" that just
controls other abstractions could be useful for other applications...
 
> I got a small error while unpacking it, but mostly it seems okay.
> (Btw: could you give v_abstractions2 a name with a suffix like .tgz?
> This will make it easier to find out what kind of file it is for
> others.)

done. (I'm not sure why the mime-type is not enough.
 
> This are very cool patches and highly qualify to be called "RRADical" ;)

Thanks! It will be pretty cool to have an integrated suite of such things.

> I'm not the one to critizise OSC yet, as I'm still learning it, but
> I'm already very fond of it after seeing how you and Eric use it. 

Visible abstraction arguments is for sure an issue, I took them out
because the only argument (the name) is in the canvas name, and
because it takes up too much screen-space (these damn v_ things
really need at least a 1024 high screen!) It does make it hard to
change the name after creating the object... 
 
> I played a bit with your patches and it way dead simple to add
> persistance with pool to it. I attached my quick-hack first version.
> The example is a slightly modified v_color renamed to osctest.pd. I
> moved the canvas a bit lower so that the patch args are visible, which
> is something I prefer. Otherwise the only change inside was, that I
> abstracted out the [pd OSC] subpatch to be a standalone abstraction
> called pdOSC (bad name, but easy to use here). This way my beloved
> Reusability is easier to achieve.

very nice. The reason why OSC was not an abstraction is that each
GOP have a different number of controlls, so ideally an OSC abstraction
would dynamically created the right number of inlets and outlets and
know what to do with the data. (This is the only reason why OSC is not
an abstraction in the first place!)

> Interestingly pool persistance, saving and reloading was possible
> without any further changes to your v_color patch. So there was not
> even a need to put a second pool object into it. It highly seems as if
> OSC and pool are an ideal couple and made for each other to be
> married. I used prepend (from whichever lib) and glue (zexy) to make
> things easier to read here. With both, arbitrary value lengths will be
> possible. 

It does sound great, I'm looking forward to what comes out of all this.

> Reloading in my exploration still requires an "OSCroute /v", but that
> could probably be cut out, too.

This is so that the OSC-in and OSC-out namespace is different, otherwise
the GOPs respond to outgoing messages!! and some bizarre feedback ensues..

Ben

> ciao
> -- 
>  Frank Barknecht                               _ ______footils.org__
>