[ANN] MMF : Max Multitouch Framework
for all you lucky maxers who have a multitouch screen :
I'm pleased to present you MMF : a Max Multitouch Framework.
MMF is a set of abstractions that will let you control very easily max UI objects directly within your multitouch screen.
MMF will work with any multitouch interface that sends TUIO messages.
here is a small demo video : http://www.youtube.com/watch?v=EEkj85GU_is
MMF homepage on my website : http://www.mathieuchamagne.com/MMF/
MMF forum to repport, criticize, share & discuss : http://www.mathieuchamagne.com/forum/
MMF googlecode page : http://code.google.com/p/mmf/
more info on TUIO protocol : http://mtg.upf.edu/reactable/?tuio
want to build your own multitouch screen ? : http://nuigroup.com/
enjoy !
MathieU
________________
Mathieu Chamagnehttp://mathieuchamagne.comhttp://www.maxobjects.com
Pretty cool Mathieu! How much does one of those Stantums cost?
How does it hook up to your computer?
Quote:Pretty cool Mathieu! How much does one of those Stantums cost?
This Stantum SMK 15.4 I use has been lent to me for a research project... but I *think* i t costs ~ 5000€...
(the 15.4 seems to have disappeared from their product page ; you should ask Stantum directly...)
Quote:How does it hook up to your computer?
it's connected to the computer with DVI and USB cables ; Stantum provides an API to get the multitouch datas, and Charles Bascou (from GMEM) made an application that turns theses messages into TUIO messages.
Mathieu
________________
Mathieu Chamagnehttp://mathieuchamagne.comhttp://www.maxobjects.com
Hello Mathieu,
All of this is of course more than interesting (bave, bave).
However I would like to know how "true" multitouch screens like Stantum ones do compare with the camera+projectors "reactable-like" setups in terms of precision, reliability and mostly reactivity. Have you compared both systems? Do you think both are fast enough for live music projects?
Best regards,
Roald Baudoux
hey Roald,
I could test a couple of camera+projectors based multitouch devices (FTIR / reactable, ..) and when they are well calibrated, with high speed cameras, and used in good light condition, precision and reactivity can be very similar to a stantum screen.
the real difference is that the stantum is like a lemur : only a couples of kilos, and almost plug&play !
the main issu with optic based system is the time needed for installation and calibration + you must have a total control on light conditions ! (no sun light, no flash, no lamp above the camera, ...)
Quote:Do you think both are fast enough for live music projects?
sure ! http://www.blueyeti.fr/Workshop-Albi-2007.htmlhttp://www.blueyeti.fr/modeles-physiques2.htmlhttp://www.youtube.com/watch?v=InY8bwlVOsg
but it depends of course of what you want to do with it ; trying to play a Chopin piano sonata on a touchscreen is a bad idea, I think..
there is always a small latency, more than a midi keyboard for ex, but I can deal with it ; you must adapt your on screen controlers to the hardware limitations (stantum & Lemur works @ around 60 hz, optic system depends of course of camera.. but with uncompressed firewire 60fps cameras, the result is very similar)
MathieU
http://www.stantum.com/en/ ( or http://www.youtube.com/watch?v=AvA6aI5eiAI )
Wow, I was just looking at the end of this video, now it looks like they have multitouch PRESSURE LEVELS sensing. I'm wondering how much their 10'' prototype cost... ( http://www.stantum.com/en/offer/evaluate )
Mathieu, I wanted to note something about the coding of your MMF :
In a discussion on your MMF forum in the topic "object drag recognition", You write:
> "testing the position of each updateCursor message
> (when draging a finger on the touchscreen) (= looking up in a coll if there
> is an object at finger pos) would be probably very cpu consuming…"
I might be wrong but in my humble opinion, in this case of fingers position tracking, the cpu consuming question looks important - only - because you use VERY low efficient ways of doing in your MMF : [coll] and Javascript.
I made some tests a while ago showing that Javascript is really not efficient for stuff that your recall very often. And [coll] is even worst. I think that if you'd put the maximum of your stuff in Java, for example, you would become really peaceful about cpu consuming : Java is about 200 times faster than Javascript or max patching:
I put theses basic efficiency tests here, about Java, Javascript, C, and some objects like [coll] : https://cycling74.com/forums/java-200-times-faster-almost-as-easy-to-use-so-why-javascript