After watching the (lame) demo of some MT features of Windows 7 running on a dell laptop. I got into wondering about what is really the best way to proceed making MT software since displays like these will become more and more available (as Windows 7 / new MacOSX / MTX / compiz) nears completion. From what I understand, this type of display doesn’t use IR light to detect finger blobs, and probably a capacitive resistance touch screen.
Having said that, is making MT software that is based on frameworks that detect finger blobs (touchlib, Lux, etc.) the best way to proceed? I understand that if you want to interact with projected displays, then there isn’t a question. But what approach to take if your dealing with displays as demonstrated above?
Well, if we use frameworks and build software that has an abstract input layer, we can support variable sorts of multitouch input, with relative ease - we only have to add support for another source as input for the multitouch software. So there would be a rather small change and addition to make to the framework if designed correctly.
Yes, I think the best way to do this is to abstract it into a unified protocol like TUIO. This way to can have “server” programs working with Capacitive, DI, FTIR, DSI, LLP, LED, Electron Guns, Sharks with lasers on there heads, whatever it may be sending out data in the same format, which is picked up by any other framework/program. Lux Definitely takes this into account, that is one of its main design goals. We have already proved this works. All those flash apps work with any TUIO Provider, be it TUIO Simulator, TouchLib, OpenTouch, or anything else not written yet, without any modification at all. We would just write another one for a different kind of screen. We have also make this model very flexible, given TUIO is based on OSC and OSC is based on UDP, we could do SMP across many independent nodes really easily. I would say things are rolling along just fine, with the exception of pushing freedom. I appear to be the only one that cares in that respect.
Flyte… capacitive systems are and will always generally be used for smaller devices, to build a capacitive system for table thats say 40-50” is goning to be pricey.... and i doubt will be available anytime in the near future… well atleast not for another 3-4 years i dont think.
Generally software is dependent on the type of situation it will be used under.... Software for MT currently is designed to be used on large surfaces where multiple people can organize, view and handle data simultaneously. The traditional OS or even Windows 7 for that matter is not designed with this mind it is designed so that one person will interact with the device at one time.
And also MT techniques being used atm will also work with LCD panels as well
Taha, this is why I think GNU/Linux will be such a great OS for this. We can modify the whole thing to support multi-touch, all the way to kernel level if we wanted(though I don’t know what we would do down there). Vlado and I are working on this, I don’t want to say anything more then that, but yeah.
So I guess there is no available software that acts as this “abstract input layer”. Maybe Lux took this into consideration?
Offcorse there is!!!! MultiTouchVista has already such “abstract input layer”. Inbox there is TUIO, multiple mice and touchlib support. You can also write your own “Input Provider”.
MPX itself is not a standard, its is a program. The plugin is being written to make MPX interact with standards(TUIO). I did not say by any means we would want to go kernel level, not even the window manager, heck, bash doesn’t even do that. I am just saying we have the freedom to, should we want to(which we don’t).
Lets agree, I don’t know anything about Windows, you don’t know anything about GNU/Linux.
Offcorse there is!!!! MultiTouchVista has already such “abstract input layer”. Inbox there is TUIO, multiple mice and touchlib support. You can also write your own “Input Provider”.
Ah. I was talking about what layer translates the input coming from the display device (tablet) that will send out the TUIO messages that the “abstract input layer” would interpret.
In other words, how is that tablet PC on the Windows 7 demo send “events” to Windows7?
The digitizer is connected using USB or COM port. Drivers read the data from port and converts them in windows api. This is like any other device on windows.
It does not make sense to use TUIO to transfer data between device and windows. But it is possible to write a program that will get HID reports from digitizer, converts them to TUIO and sends them to MT program. That is how works (without converting in TUIO) MultipleMice input provider in MultiTouchVista framework.
