BBTUIOTest bugfixes

The clever NUIGroup member Aureau found a nice juicy bug in BBTUIOTest app. (these sorts of things will happen :-)

Turns out I had read the TUIO spec to say that the message order in the TUIO bundle are generally in the order:


however, this is not necessarily the case. (at least not using the reactivision TUIO Simulator java app, which sends source,alive,set,fseq). SO! my bad. Anyhow, it is now fixed for that bug.

I also added the ability to fake mouse events, however, i will say that I have not worked all the kinks out of that transaction, so use at your own risk. (I have done some testing and the worst thing that seems to happen is that the mouse gets stuck ‘down’, in these instances, just hit command-option-ESC and it will reset the mouse events. You don’t need to actually force quit anything, just the act of opening that window will reset the mouse events) Also, the mouse events will be ‘faked’ on the selected screen, presumably the same screen that you have setup for your projection. (also note: that code is still a bit raw, so there probably aren’t as many comments as there needs to be)

Anyhow, here is the code bundle, with binary:

I guess fairly soon i will have to make this into a real project on google code :-) it seems to be turning into a ‘thing’


This entry was posted in code, multitouch, openSoundControl. Bookmark the permalink.

7 Responses to BBTUIOTest bugfixes

  1. ajlovegrove says:

    Hey Ben. Just wondered if you had made a mouse driver for OS x? Somthing that will act as a single touch interface?

    Xelapond tried it but as he doesnt have a Mac it made it hard to test.

    Have you had any luck?


  2. Ben says:

    Hey AJ,

    in fact i have. Kinda. this BBTUIOTest app (the newer one) has a ‘fake mouse events’ checkbox that will in fact fake mouse events. However I haven’t had too much time to really test and refine it.

    (i did some simple testing, and was able to drag windows around and click on stuff on my desktop)

    It isnt really a driver per se, but it does the job. it takes the first blob that it sees and makes that the mouse blob. (mouse down) moving the mouse blob will do a drag, and taking your finger off the surface will do a mouse up. if you have more than one blob, it will ignore the extras until you take the first one off, then it will go to the next one and think that is the mouse.

    Give it a go and let me know what it does :-)


    ps: as i mentioned above, if it locks up your interface, just command-option-esc. that will reset the mouse events (it seemed to get stuck in the down position sometimes, i think i fixed that bug, but again, havent had time to really test it out)

  3. ajlovegrove says:

    Perfect! I will test it when i get home, This is kinda the reason i started the whole multitouch escapade in the first place, So i could have one great big touch screen for VJing on!

  4. ajlovegrove says:

    Sorry Ben if i had actually read the last post i wouldn’t of had to ask you such an obvious question! Anyways nice to chat!

  5. sandor says:

    Hey Ben,

    having a lot of problems with BBtouch. I have tryed out with a DI setup and also with an FTIR setup. The blobs are very erratic and unstable. Often i don’t get any of them ;-)

    I have upped a few screens of BBtouch to illustrate what’s happening. As you can see on the screens the “dark blobs” and the “white blobs” are realy good…

    Maybe do you have an idea whats happening there… Maybe we need some more filter stuff?

    The same setup works realy well on windows with TouchLib (exepting the camera correction with the barrel_distorsion filter)…

    I have also seen that the realy nice distorsion settings in BBtouch have also a problem:

    – even if you set up the grid correctly, the ROI (the rectangular thingie) will still catch up evrything inside. So if you have a larger display and you have to use a fisheye lens, you will allway catch up the brightly lit areas on the side. This will be even more complicated if you are forced to put you camera on the side of your bos and not in the middle. Would it be possible to distort the ROI rectangel also? I mean in a way that the 4 edges don’t have 90degrees….?

    Oh, her’s the DL link:


  6. Ben says:

    Hey Sandor,

    first the ROI thing, yes definitely. I already have some stuff in dev that fixes that problem (and makes the detector just a wee bit faster too (since it isnt looking at all those pixels that we dont care about) but it probably wont be done for another week at the very least. However, even tho the edges are getting detected by the detector, it wont make it out as a blob because it doesnt fall within the camera mesh.

    now, for your blobs: hmmm… all those camera shots you have should be making perfectly nice blobs. I am not sure why they arent. The only thing I can think of off the top of my head is if you are switching between FTIR and DI on the same table but maybe not resnapping your background?

    just some general thoughts:
    tiff 1: looks great!

    tiff 2 : threshold is at 81, that is pretty high, try turning it down all the way until you start to get really bad false positives, then crank up from there.

    tiff 3,4,5 : this looks dandy, don’t know why you aren’t getting blobs here :-( as i said, the only thing that comes to mind at the moment as a background image issue? (maybe i need to add a button that allows you to see the subtracted background result? that is probably a good idea, then you would know right away if you needed a resnap)

    also have a look at the console and see if there are any errors popping up. Your blobs look really great (nicer than mine), you should be getting nice clean detection. hmmm…

    let me know if any of this helps, and I will think some more on it and see if i can think of anything else.

  7. sandor says:

    Hey Ben,

    thanks for the reply! That’s great with the ROI thingie! For the tests i had to scale down the ROI to a small part of my visible image area for that reason. Would be great to see that new function soon ;-)

    As for the real problem:

    I have spent the half night in the office doing some in-depth testings on windows and OSX.

    As you can see we are getting opticaly very good results. This is becose we are doing a “new” way of illumination/projection technique. Just to give you a taste: we are “flooding” the projection surface with 72 Watt of light ;-) Unfortunatly i cannot diclose too much here (maybe private mail?) on the process we are doing. We are right now not sure if we should make our approach open-source or not… But fact is, that we have a “rest image” of appr. 3-7% of the projected image. Working with TouchLib and the provided filters this is neglectable becose after the filtering the camera does not seeing this 3-7%…

    But this does not realy helps with the problem. Tiff 3,4,5: what you see there are 3 coins placed on the surface. I have made right now a new test: No movement in the front of the surface. The projection does not have any structure, so that the background cannot be an issue. Background removal was done. I just have placed some objects on the surface to create blobs (unfortunatly also my Zippo – after that i was searchning for a few minutes for my lighter – LOL!) Here i am getting blobs at a treshold value of “45”. Putting my hands gives me realy erratic values. But not just this: see what’s happening if you connect BBtouch over FLOSC and TUIO to the “paint.swf”… LOL:

    Well – complicated stuff that is! I quess i’ll have to do some more work here.


Leave a Reply