The flosc gateway was not updated?
I was using the one that came with 1.0 even after I upgraded to 1.1 (was cached in terminal so I could just hit up to bring up the last command, then hit return).

It crashed every time I had over 5 blobs.
But the flosc gateway that came with tbeta 1.1 seems to handle more.

Is that just a coincidence?

Yeah, it’s the same FLOSC. So that’s very weird.

It could be all in my head.
I was using the icon in my dock and they both claim to be 1.0, so maybe I was using 1.0 when I thought it was 1.1 and only started using 1.1 after I changed the flosc?

What ever it was,

I know 1.0 crashed with 6 blobs.
1.1 does with 15 blobs. (just checked)

cerupcat - 10 November 2008 02:29 PM

Yeah, it’s the same FLOSC. So that’s very weird.

Hey Seth,

just a quick note from me: the issue with Quartz Composer and tBeta still alive. Just double checked that now, because some people are having problems with the QC stuff at xTUIO and tBeta… Or did i missed some infos regarding QC and tBeta (beside this thread)?

Cheers,

Hi Sandor, can you remind me of the current problem? More than 5 finger crash or is it now a higher number?

Hey Seth,

well actually tBeta won’t transmit any TUIO information to QC. I have checked the settings in both tBeta and QC (the i’m using the TUIO patch by Martin Kaltenbrunner). They are both set to 3333. The reactivision tracker, the TUIO simulator and BBTouch are passing the TUIO values as supposed, but nothing comes through from tBeta. What could i provide you to help identifying the problem?

Greets,

oh ok. This is probably because tbeta sends height and width data. The reactivision stuff needs to be edited to support these 2 extra values. Touchlib also sends height/width (of course it doesn’t run on mac though). This same issue is with MAX/MSP and PureData. We’ve updated those clients to support the extra two values and they work now. In the future we might also add finger angle value so the list may expand even more.

It looks like we’re gonna have to setup a NUI Group tuio client page since the reactivision clients don’t really line up with expansion we’re doing.

Hey Seth,

yeah that makes sense… I just had a very quick look at the TUIO sourcefiles. It seems like “angle” is allready supported, but not the width and height of the blobs. Could you maybe post the structure of the data tBeta is sending out - maybe so that a newbie like me can understand that If i have some time i would try to extend the TUI QC patch with those datatypes. But i think it would be maybe better to inform Martin about the problem - also i am not sure if a different set/type of “special” NUI based patches would really make sense? Ist that not confusing on the long run? Would it not be better to extend/improve the existing ones and unify that with the reactivision stuff - of course only if Martin has an interrest in that? Me personally would love to see that MT apps based on TUIO can work flawlessly no matter what tracker we decide to use. I mean any of the xeisting tracker hast their pros and cons…

BTW: is there a nice godd soul who could/would test out some of the stuff over at xTUIO also with Touchè? Sorry Georg, but i was unable till now to set up Touché correctly on our table (i’m sure this may be some special limitations of our table setup - and also the leck of time...).

My2c,

Hi Sandor,

Yeah I understand and it’s a bit hard to explain. Basically, we’d like (in tbeta at least) to send extra parameters that we think people would use in their applications. Unfortunately, this means that TUIO Clients have to be updated to account for this. It’s not really a problem with the current reactivision tuio clients. It’s more that the clients are written for reactivision and therefore other trackers have to send the same format and parameters in order for them to work (which isn’t ideal). I will talk to Martin, but I’m not sure it’s really an issue with his work since we’re the ones changing it. I tend to think of the clients on their page as reactivision tuio clients and not necessary global tuio clients since they’re meant to be paired with reactivision since that’s their focus.

However, it should be possible for different trackers to work and we won’t need different TuioClients for different trackers. For example, in the TUIO Client if we put:

if(parameters == 5){then do normal 5 parameters}
if(parameters == 7){then do 5 plus width/height}
if(parameters == 8} then do 5 + height/width + angle}
if(parameters == 9} then do 5 + height/width + angle + pressure}

and that way it’ll still work whether we’re using tbeta or touche or bbtouch etc. There may be an even smarter way to do this and I can ask Martin about it. In the end, this will require that nuigroup hosts it’s own set of updated clients so that we don’t bug Martin to update something he doesn’t use.

Tbeta sends the same parameters and order as other trackers and at the end, we also send width and height. So if you’re able to add those two parameters to the client where it parses the current ones, you should be set. I’ve looked at the code a bit, but it seems to be in obj-c which I don’t really know. I’ll look deeper into it tomorrow though and see if I can help recompile it to work on all trackers.

I’m sorry for the troubles. Let me know if the above makes sense or if you have another view on this.

Hey Seth,

that makes sense again. I see the problems with the unifyed clients. I also have to admit that sending out additional info like height/width + angle + pressure (pressure would be defined by the blobsize i assume?) would be more than charming… I could also imagine to implement this datatypes into BBTouch - of course only Ben would like to support that - or i have a special need for that BTW: the native Xcode (cocoa) apps like xPREXXO and xNODER (coded by Ben) are working like a charme with tBeta - so it is really that QC TUIO client only…

But anyhow: it would be great if you have the time to look at the code tomorrow - i’m sure it’s more effective than what i can do

Thanky you again for supporting this esothericl problem - i appreciate this very highly!

Cheers,

Ok, I’m attaching a test plugin that hopefully works with tbeta. I couldn’t really test it as I couldn’t figure out QC very well. Let me know if it works with tbeta or not. If it does we can start to setup a proper release/page for this stuff. I just finished updating the Max/MSP and PureData clients also. I contacted Martin and awaiting a response to see if he has a recommendation about keeping trackers compatible while parameters extend.

If you’d like to chime in where I posted to Martin, you can visit: http://sourceforge.net/forum/forum.php?thread_id=2859463&forum_id=515398

Hey Seth,

just made some quick testings with the new plugin. Here are the results:

TBeta: seems to work fine. Also the “width” and “height” is shown up in the transmitted structure
TuioSimulator: the plugin does not recieving the cursor data, fiducials however are transmitted to the patch
Reactivision: same as TUIO simulator, only fiducials are recieved by the TUIO patch
BBTouch: does not working with the patch… no cursor data is recieved by the TUIO patch
Touchè: sorry - cannot test that since i did not managed to run Touché with our table…

So there seems to be a little bug somewhere…

But anyhow: a great starting! If you would like to test the plugin by yourself, you can get some QC compositions from http://www.xtuio.com
(take the xFLOYD example, that should be quite clean. There is a binary and also the QC sourcefile in the download zip)

Cheers,

Seth (cerupcat) - 25 January 2009 11:21 PM

Ok, I’m attaching a test plugin that hopefully works with tbeta. I couldn’t really test it as I couldn’t figure out QC very well. Let me know if it works with tbeta or not. If it does we can start to setup a proper release/page for this stuff. I just finished updating the Max/MSP and PureData clients also. I contacted Martin and awaiting a response to see if he has a recommendation about keeping trackers compatible while parameters extend.

If you’d like to chime in where I posted to Martin, you can visit: http://sourceforge.net/forum/forum.php?thread_id=2859463&forum_id=515398

No this isn’t a bug actually.

My changes will break trackers that don’t send height/width. I couldn’t find a way to make it work with both right now.

This means, if people are using tbeta (or touchlib) that they need the one I posted and if they’re using bbtouch, reactivision, simulator, or touche (assuming touche doesn’t send height/width) then they need the original one. Of course this isn’t ideal, but until we come to a conclusion how to really properly extend TUIO, this is probably how it’ll be for a short while.

Martin and I started a new discussion on NUI Group here that you can read: http://nuigroup.com/forums/viewthread/4218/

P.S. - I’ll try out ofxTUIO when I get a chance to test I’m not normally on mac, so it’s not always easy.

Hey Seth,

thanks for the explanation and for the link to this very interresting discussion. I like actually both ideas: extending the protocoll with custom profiles and als the idea of a TUIO2 protocoll. In the mean time we just could use the two different plugins for QC as an intermediate solution. The only thing needed would be to give another name to the plugin (tBetaTUIO or whatever). Could you maybe compile a new bin with a different plugin name if you have the time? I would than try to implement a simple switch in the applications where the user can choose between the different trackers…

Thank you very much for your efforts!

Cheers,

Yeah, when I get a chance I can see if I can change the name. I think it may require changing a bunch of the name stuff so we’ll see. In the meantime, you might just want to include on your website for people to replace their current client file with this one if they are using tbeta. Keep in mind, this is being done with the intentions of this ‘fix’ being temporary as we want to comply as much as possible with Martin.