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__