Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
I've added OSC names to my GOP abstractions as /v/[name]/[param] I did not put in another level to group the different abtractions /v/rotate/[name]/[param]. (I just do that stuff with naming in the patch /r? for rotate etc..)
I have been using these OSC names interally as well, to control things programatically at the same time as through the GUI. These have the same names without the /v/ part (I was having feedback loop issues!)
It would be pretty cool if these Gem GOP controls could be compatible with the audio stuff... (over network or locally)...
I don't see why they couldn't be compatible. It's seems to be just a matter of coordination.
I've put my current version of gem abstractions on pure-data:
http://www.pure-data.org/Members/bbogart/v_abstractions2/view
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.)
This are very cool patches and highly qualify to be called "RRADical" ;)
Pay most attension to the abstractions named v_* I included some early examples. I'm also open to critisisms as it comes to my usage of OSC, since I have made it impossible to send OSC controls that go beyond the scale of the GUI objects... (because I want the GUI to update based on the OSC commands)
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.
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.
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.
Reloading in my exploration still requires an "OSCroute /v", but that could probably be cut out, too.
ciao
Frank Barknecht _ ______footils.org__