event handling + muliple sockets

hi all
so i’ve been plugging away at a multitouch app for a while now. finally getting somewhere with event handling since the 06 release but have hit a snag.

i added the tuio event handlers to the ofxMSAInteractiveObject and all was working when testing with one object. But when i create a second instance i get:

terminate called after throwing an instance of 'std::runtime_error'  
  what():  unable to bind udp socket  

at present each object tries to create it’s own tuio client, which has it’s own osc receiver on the same port and i get the error above.

i am a bit confused about the best way to proceed. if i can’t get around the socket problem, then i guess i need to create a single tuio client, and get the other objects to listen to it’s events somehow?

event handling is new for me so any advice greatly appreciated. I have attached my test code if it helps - needs the ofxOsc to compile

receives finger/cursor values from the tuio simulator:


i have a naughty workaround for this to tide me over. i have made an instance of the tuio client as a global variable. all objects then refer to this for their event handling.

If it might help, I have a version of ofxTUIO that can be used with multiple TUIO clients… each one on a different port though.

Besides that, instead of a global variable, you could make your myTUIOClient object a pointer, and add a setTUIOClient method. Then initialize it in your testApp, and pass it to each of your objects that need it.

Or you could make the TUIO events actual oF events (poco) analog to setup, update, draw … It’s easy once you wrap your head around :wink:

You can use ofEvents.h as a starting point. Basically you create a class ofxTUIOEvents and define all the events as members. This class you instance and make extern so you have access across all you files/classes. Name it something like tuoiEvents.

To use these events you need to register listeners and also properly call them from the TUIO client code. This is what ofEventUtils.h is for.

You can then register listeners to it like this:

ofAddListener(tuoiEvents.anEvent, this, &Class::method)

“this” is the instance with the method that will be called when the event fires. “Class::method” is the actual class and method name.

The signature of this method should look like this.
void method(ArgumentsType & args)

And trigger the events like this:

ofNotifyEvent( tuoiEvents.anEvent, myEventArgs );

Let me know if you have questions,

hey stefanix, the ofxTUIO add-on does use oF events… it was actually using POCO events before 0.06 came out :stuck_out_tongue: The newest version updated to use the 0.06 style events like you described.

I think they are meaning that they have instances of objects that each have their own tuioClient object and are acting as a listener on it. The problem is that each instance of a tuioClient wants to open a udp socket… and it won’t allow more than one socket open on the same port.

Ah cool. Maybe I should look at the TUIO code before I talk …
Maybe you can point me to the latest code.

Seems to me that there should only be one instance of tuioClient which notifies the tuioEvents. All the other objects should just register with and listen to the events. For some reason I thought all the tuioClient objects are there because the addon was not yet using the new event system.

Sure… the latest ofxTUIO is available here (0.6 version)

add-on page: http://addons.openframeworks.cc/projects/show/ofxtuio

thanks all for your feedback.

and thanks plong0 for the pointer suggestion as I do need to have the same port for each client and i guess that’s the best practice way to do it.

no problem nay.

If you really don’t want to be passing a TuioClient pointer around, then there is another method that I usually use for my TUIO-based apps…

With this method, the testApp is the only one with a reference to, and only listener of the myTuioClient.

Any TUIO or mouse events are captured by testApp, and then sent to a single checkCursor function in my top-most GUI object which then delegates it to any child elements it has. I like using a container style GUI object to keep testApp cleaner and also gives the advantage that if you have multiple GUI objects, you will be able to manage which ones actually take action on the event…

For example, if you are implementing a dragItem functionality that you want to only act on the top-most element. With the single-listener approach, you’d be able to stop checking as soon as the event is handled by one of the children… versus the approach where every item is listening and receiving the events, each item has no idea what the other items are doing with it, so you have no way of making the action mutually exclusive.

This approach also ends up causing all mouse and TUIO events to be treated the same way as far as the GUI knows (I mean they don’t have to - but for me it’s usually a lot simpler to treat them that way because I write 1 method instead of 2). The trick I use to prevent clashes between cursors is to use a string cursorID… for the mouse this would be “0”, for TUIO events, I use : (so I could potentially add more TUIO clients later on with no conflict).

Hope this helps!

PS. I have an example of this method that I am hoping to release really soon. It’s basically a generic multi-touch gallery add-on (like for photos, videos, etc - it’s generic so you can define your own galleryItem types). I have it pretty much done and working right now (including a few different GUI modes - ex. grid, scattered, etc) but there’s one last feature I want to finish before I make the official release. I guess if anyone is really desperate to have it right away as a reference or whatever, I could email it as requested by private message.

Thanks, that is super helpful as I hadn’t even thought about dealing with overlapping objects yet! I look forward to taking a look at that example when it’s ready.