Multi-Touch

[mathew davis]

On 4/3/07, adrian cockcroft <adrian.cockcroft at gmail.com> wrote:
>
> This is key:- "Pressure has almost no effect on a single touch, but
> not so on a double touch. The relative pressures will cause a
> significant skewing effect towards the harder touch. You can easily
> move the pointer along the line between your two fingers by changing
> the relative pressure."


So we will not see clearly defined bounding box limits. The point will
> skate around within the limits depending on relative pressure.


 So I guess we need someone with a device to test this and see how much
pressure actually affects the neo touch screen.  With that information I
think we could see how easy it would be to get an average bounding box
approximation..

The first finger will set a clear start point, the second finger will
> make that point shoot off towards it, but it will not go all the way
> to the second touch. The effect should be to oscillate along the line
> between the two end points, and it wont return to the position of the
> first touch.
>
> If we capture a clear single touch, and an average position of
> oscillation, then we can take the average oscillation to be the center
> of the bounding box, and project an estimate of the opposite corner
> where the second touch should be. With the right filtering and
> limiting algorithm it should be possible to get the effect we want. If
> we can give visual feedback on the screen showing the touch points and
> bounding box it may help the user control the input better.


Ok so what if this feature was disabled by default.  Since enabling it might
slow some functionality.  When the user enables the feature he/she will have
to go through a config which does a calibration.  The user runs through
several scenarios where the program can gather the relative pressure
difference in known circumstance with the desired result known as well.  It
could then store that information in a database based on which user is using
it, if there are multi users, if not just store it in a config file.

Challenges: In comparison with a true dual touch input device, its
> going to react more slowly as the algorithm will need to gather more
> data to decide where the pointer should be. Some of the faster moving
> single touch gestures may be hard to distinguish from multi touch.
>
> Adrian


I agree, but it would still be a nice feature to have and I could deal with
a little lag for added feature especially if I could enable it or disable
it.  With the single touch fast gestures we could set that up inside of the
calibration also.  That way if it thinks it's multi touch it compares it
with it's database which links it to the single touch fast gesture instead.
It would be slow but you could disable the multi touch option and then
single gestures would be fast again.  Or we could have the multi touch be
enabled in certain programs like web browsing or picture viewing, and
disabled for the rest.  But I think a simple button in the header or footer
should work alright.  You could have it turn green when active and red when
deactivated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20070403/28a17c00/attachment.htm