Archive for the 'multitouch' Category

out on location

Published
by
Ben
on September 2, 2008 11:10 am
in multitouch
. 0 Comments

Hello All,

I just wanted to post a quick apology for being unresponsive to the latest batch of emails and comments. I got called out on an 'emergency' film shoot last friday afternoon to fix some motion control rigs and wont be back until this friday at the earliest. (i say 'emergency' because it was their emergency, not mine :-) i just had to pack up and leave in a hurry to come and get it working again)

quickly: Sandor, Drills, I think that there must be an issue with the mapping stuff that was added in the last big release. I will have a closer look at that stuff with your issues in mind and hopefully find a smoking gun somewhere in the code.

Todd, i will have a look at your project and see what I can find, but probably wont get the time until this weekend (maybe friday) . However if you want I would suggest that you make a mac-based cocoa app that does what you want, and then when that is working, port it over to the iphone. it is a bit easier to debug and fiddle with the cocoa/mac apps and if desiged right you should only need to replace the UI code.

Brent: I don't think that was our gear at the DNC. But then again they never tell me anything :-)

i have probably forgotten someone/something but i will get to all of it when i get home, i promise :-)

Cheers!
-b

BBTUIOTest bugfixes

Published
by
Ben
on August 25, 2008 10:22 am
in code, multitouch and openSoundControl
. 7 Comments

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:

source
set
alive
fseq

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:

BBTUIOTest-1.app.zip

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'

Cheers!
-b

More Bugfixes

Published
by
Ben
on August 22, 2008 4:11 pm
in code, multitouch and openSoundControl
. 0 Comments

Here are a handful more bugfixes that I committed a few minutes ago:

  • thanks to the keen eyes of Georg of the Touche tracker fame who spotted these bugs: The TUIO auxiliary parameters were all messed up. (like velo, accel, etc) now they are fixed.
  • fixed an anooying little display issue where the blob view would sometimes cut off one of the blobs.
  • fixed a problem where the projection mesh rotation handles were in the wrong place on large resolution screens.
  • made the drop dead detection shutoff time 4 seconds instead of 1. (i still need to make some of these magic numbers into configuration options)

    That is it for now :-) let me know if there are more issues.

    Cheers!
    -b

    • Minor BBOSC framework update

    Published
    by
    Ben
    on August 22, 2008 7:58 am
    in code, multitouch and openSoundControl
    . 4 Comments

    I forgot to mention yesterday that I committed a minor update to the BBOSC framework. It was a single method call to allow convenient access to the attached objects of a packet.

    This came about because i never really 'finished' the dispatch side of things. Now (with the one added method call) you can in fact add your own dispatch code pretty easily. I had thought to bolt on a nice registered callback kinda thing that decompressed the messages and bundles and sends them to callback registered by address, but i haven't done that yet. It still works fine without that nice feature, it jsut means a tad bit more work if you want to do any complicated message dispatching.

    In any case, if you are a big BBOSC user, you should probably get the updated code and recompile. (I know that the TUIOTestapp i wrote yesterday requires it :-)

    That is all for now!
    Cheers!
    -b

    Multi-boxing BBTouch

    Published
    by
    Ben
    on August 21, 2008 5:49 pm
    in code, multitouch and openSoundControl
    . 0 Comments

    I have given a great deal of thought to the idea of adding a nice distributed object system to BBTouch. that way you could have cocoa-based clients easily hook into the blob events to do their own thing. I have used DO in a bunch of my other projects and it works well and is simple to use.

    However, I also spent a bunch of time getting TUIO to work with BBTouch. And there are already a whole bunch of applications that can utilize BBTouch as a tracker because of the TUIO stuff. So it occurred to me that since BBOSC is basically done (it could use a nice dispatch system, which i will add someday, not to mention lots of error checking and lots of general spiffying up, but i digress) it makes far more sense just to build any new BBTouch client apps using TUIO as the base protocol. I dont think the performance gains I would get by going with DO would be all that staggering (if there we any at all). Also, if i write my cocoa client apps to be all tuio-friendly then people can use them with whatever tracker they want to (like a PC-based tracker or a yet to be designed all-hardware tracker.. whatever.)

    And, the most important thing, as i mentioned earlier: it is already done.

    So, I have hacked up a quick TUIO cocoa client app that plays nice with BBTouch (and theoretically should play nice with any TUIO tracker).

    isn't it cute?

    Clever viewers will recognize many of the elements (since i basically just dragged them all from BBTouch into a new project and bolted on a TUIO dispatcher).

    Anyhow it is super-duper simple. Anyone who wants to write a client app in cocoa for BBTouch (or for any tuio tracker) can use it as a starting point. It runs on nicely on really old hardware too. (at least it runs perfectly nicely on my 866MHz g4 laptop, which was collecting dust on my shelf, now it is my projection server :-)

    I should admit that the real reason i did this was because due to the craptacular firewaire destruction fest of two weeks ago, my second best machine is now without firewire support. (it was the main machine I was using to test all this stuff on). That left my main macBookPro as the only machine that could run everything. This is fine except that I really really have my workspace all dialed in. Big cinema display, keyboard at the right height yadda yadda.. hooking the MBP up to the table meant unhooking it from the big monitor :-( and that was a pain. So I wrote this remote TUIO app mostly so I could still use the MBP as the 'camera' machine, and still have the benefits of the big monitor for developing and whatnot, and my really old machine gets to be the 'projector' machine, and my not that old but not that new machine gets to go back to being my entertainment center. everyone wins.

    In any case, if anyone wants it: here is the TUIO Test app.

    BBTUIOTest.zip

    As I mentioned before, if you want to write your own Multi-Touch client in Cocoa, this is a good seed to start off with. It is the absolute bare bones TUIO + View implementation (with a tiny bit of gratuitous core animation). Have fun!

    Cheers!
    -b

    Some bugs that I done fixed

    Published
    by
    Ben
    on August 20, 2008 12:12 pm
    in code and multitouch
    . 8 Comments

    So, I probably committed all that code just a wee bit early. Here are a few silly things that i missed, but are now fixed:

  • dark blobs: now they work again.
  • added some minimal UNDO functionality, mostly centered around the meshes. now you can undo any flips, expands, and new mesh commands. More UNDO for other things (like dragging vertices and such) coming later.
  • changed the TUIO coordinates to normalize against the screen rectangle instead of the mesh bounding rectangle (seems like a more standard way to do it)
  • removed a slew of spurious debugging logs.

    So! r120 is what you are looking for now. that is the most bestest.

    I tried to upload the binary to the google code site, but for some reason it is barfing on my password and login (not to mention it never asked me for a secondary login/password when i uploaded files before) so i think something is busted there.. anyway, until i get that figured out here is the r120 binary:

    BBTouch.r120.app.zip

    EDIT: Pawel fixed it, so now you can get the binary from the binaries link on the sidebar.

    • New BBTouch Quick Start Guide

    Published
    by
    Ben
    on August 19, 2008 7:05 pm
    in code and multitouch
    . 0 Comments

    Just up there on the main nav bar. hit 'BBTouch'.

    Groovy!
    -b

    BBTouch Code r113 is up!

    Published
    by
    Ben
    on August 19, 2008 3:37 pm
    in code and multitouch
    . 8 Comments

    I have committed all of my most current changes to the repository and uploaded a binary for those who are compiler-averse. The links are in the sidebar. I am putting together a BBTouch quickstart kinda tutorial now, but if you follow along with the last few posts you should be able to get it all working. Let me know if (when) there are problems!

    Cheers!
    -b

    Just a teaser

    Published
    by
    Ben
    on August 19, 2008 12:48 pm
    in code and multitouch
    . 0 Comments


    BBTouch calibration with lots of photos

    Published
    by
    Ben
    on August 18, 2008 6:31 pm
    in code and multitouch
    . 2 Comments

    OK! so here is the basic calibration process:

    first: calibrate the projection. This means that you need to drag your mesh vertices around until they fill your desired projection area.


    This is a test calibration, which is all skewed to make sure that it can handle when the camera and the projection are misaligned. In a 'real' situation you would stretch the mesh to cover your entire usable surface.

    In the mesh views, if you hold down the shift key, then you get some handles that allow you to scale and rotate all the vertices together. (shown in the first shot at the top) otherwise you just drag them around one at a time.

    After you get your projection mesh set up the way you want (takes about 30 seconds), you leave the projection mesh up on the surface, and switch to the camera view. I took my visible light filter off so that i could see the mesh in the camera view:

    notice that the mesh is 'keyed' with a circle at one corner and a square opposing it. this is so that you can make sure that everything is facing the right direction. In this case i just need to flip it horizontally (with the handy button for just that purpose)

    Now just like in the projection mesh, you drag, rotate, and scale the mesh until it is close to the right size, then you manually move the vertices into position: (make sure the keys are right!)


    almost there....


    a finished mesh calibration. start to finish: about 3 minutes.

    Just in case it is inconvenient to get to your camera and filter, you can easily do this a bit more manually with some printer paper and a sharpie:


    a couple of sheets will do it... just lay them on the projection mesh and mark the vertices with a big black marker (but dont use one that will bleed through) alternatively you can just put stuff on your surface, coins, or toothpicks, or anything that will show up.


    Be sure you can see the 'keys'..


    Here is the camera shot, with visible light filter.


    Here is the finished mesh. This way is a bit more time consuming, but i still managed to do it in about 5 minutes. (most of that time i was looking for my marker :-) Since the marks were a bit hard to see i had to do some back and forth with the mesh visibility and took me a bit longer to get the vertices matched up, but wasn't too bad.

    Currently this calibration requires that your setup have a monitor that is not your projector or it gets a bit more difficult (it is possible, you just do the manual paper-marker route, then switch to the camera view, the downside being that you have to work through the sheets of paper laying on top of your surface which would be a bit of a pain. I am going to add a 'camera snapshot' ability so that you can project the mesh on the surface, take a snapshot, then do the camera mesh. That way you could do it much easier with just your projector as a monitor.

    In any case, tomorrow is all about getting the calibration views working in the right order, cleaning up the code and doing some full blown tests and hopefully posting some code for all you to try out (tho it might be Wednesday, but I am optimistic :-)

    Cheers!
    -b