| Author |
Message |
| < Talk to the developers ~ receiving TUIO or other complex OSC, and forwarding to QC |
|
Posted:
Mon Nov 16, 2009 6:07 pm
|
|
|
Video Architect
Joined: 25 Mar 2007
Posts: 171
Location: London, UK
|
|
Hi all, sorry for the long mail, but I wanted to make sure I didn't omit any detail in what I want to do... which is:
1. On one mac I have a custom app sending lots of data using OSC (this may or may not be TUIO, more on that later)
2. On same (or another) mac, I have a few (5-10) different QC visualizations loaded in VDMX and they fade in and out, or different visualizations are triggered at different times etc. This is all pre-sequenced or triggered in realtime by user etc, and they are all controlled by the same OSC data.
My question is, how would I set this up in VDMX in regards to receiving the OSC?
I can't use the OSC Receiver in each QC composition, because only one composition can open the port at any given time, so will not work. I want to be able to have multiple visualizations running simultaneously, and adding new QC visualizations to the system should be relatively straightforward.
So I think I need VDMX to forward the OSC data to each of the QC Compositions. VDMX doesn't actually need to parse any of the data, or know what is going on in the data, or react to the contents of the OSC data, it just needs to pass it on.
The OSC data I'll be sending will be quite big, so I can't individually 'osc learn' VDMX sliders and then assign them to published inputs for each QC patch. There will be hundreds and at times thousands of bits of information - tracking lots of (variable number) blobs, contour information (variable number of points per contour) etc.
A solution that came to mind is:
1. Create a QC patch that receives and parses the OSC data, creates a structure with all the data and publishes that as an output.
2. Use that as a qcPlugin.
3. Each of the QC Visualizers have a published input which expect a structure
4. in VDMX assign the single published output of the qcPlugin to each of the published inputs of the QC Visualizers.
This way the UDP socket is opened only once, the OSC data is parsed only once. And adding new QC visualizations to the system is very straightforward, just need to assign the qcPlugin output to the published input of the QC Patch.
Unfortunately of course, I cannot do this because I don't think structures are supported in VDMX.
P.S. The OSC protocol I'm going to be using is almost identical to TUIO. In fact it will be exactly the same except I will be sending contour information as well (an arbitrary number of x,y coordinates per blob), and possibly some other data. So for now I am just testing with TUIO, and using the QC TUIO Client. This does exactly what I want in my desired solution step1 I mention above (receive the OSC data and output a structure - a variable length array of dictionaries).
http://sourceforge.net/projects/reactivision/files/TUIO%201.0/TUIO-Clients%201.4/TUIO_Quartz-1.4.zip/download
So any advice on how I can achieve something like this would be much appreciated!
Cheers,
Memo. |
|
|
|
|
|
 |
|
Posted:
Tue Nov 17, 2009 1:54 am
|
|
|
Video Architect
Joined: 10 Jul 2004
Posts: 1083
|
|
hi memo-
vdmx's support for quartz composer extends to creating UI items and passing UI-related data back and forth between compositions. we do this so users don't have to worry about creating a UI; the only thing they have to do is put together an image-processing backend in quartz composer.
you're asking us to support the sending and routing of data which can't really be used by any other aspect of vdmx; while what you're proposing sounds cool (and a great deal like a multi-touch UI setup), we can't in good conscience spend a lot of time working on something that's only really going to be useful to one or two people and falls wholly outside of the scope of vdmx's intended use; that just wouldn't be fair to everybody else until vdmx is more complete.
the upshot of all this is that you're not going to see native support for sending/receiving abstract data structures as an interface item in vdmx in the immediate future. the sending/receiving of data between compositions you described is basically considered to be part of your composition's backend.
in the meantime, you should be able to accomplish this relatively easily by building a pair of QC plugins (named, for example, "send" and "receive") which communicate with one another across compositions. stuff you send to an instance of the "send" plugin will be received and processed by instances of the "receive" plugin; this can be used to pass data between different instances of compositions open within the same application (or even different levels of the same composition). here's a .zip with two xcode projects which should get you started; please note that the plugins contained within it are just a functional proof-of-concept which demonstrate that this is possible, and require further work before you'll be able to use them in your setup.
http://www.vidvox.net/rays_oddsnends/memo_dataRouting.zip |
|
|
|
|
|
 |
|
Posted:
Wed Nov 18, 2009 9:05 am
|
|
|
Video Architect
Joined: 25 Mar 2007
Posts: 171
Location: London, UK
|
|
Hi Ray, that sounds like a perfect solution thanks, will give it a shot.
Quick question, what is the best way to keep the QC patch that has the osc receiver (and the notification sender) always running? Do I make it a VDMX qcPlugin? Or just trigger it on an empty layer and keep in the background? |
|
|
|
|
|
 |
|
Posted:
Fri Nov 20, 2009 6:18 am
|
|
|
Video Architect
Joined: 10 Jul 2004
Posts: 1083
|
|
| i don't think it really matters, but a plugin would probably be easiest to work with... |
|
|
|
|
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|