http://gestureworks.com/

Thought this might be of interest, it drops July 15th. works with TUIO events, on HP and Dell hardware as well as the snowflake setup. They compare performance to touchlib.

from the site:
“ActionScript developers can associate gestures with objects and layers as simply as mouse events are handled. For example, here is what is required to make an object scaleable (with a multitouch gesture) in ActionScript:”

nice!  Looking forward to seeing what all this can do.

Should be interesting to see.

I don’t really consider any of those things as gestures though and rather I think of them as direct manipulation. I think our current classes are comparable as far as ease. For example you don’t need an event to move or scale, you just extend a class that already does this (testSquare extends RotateScaleMove). I’m not sure if writing MT the same was as writing for mouse is best as that keeps the same mentality as writing for mouse which is really a whole different approach (at least if we’re trying to innovate new interaction).

I’m still excited to see the release and it’ll be interesting to see a different approach and whether it’ll be a step forward and not.

Really good point Seth, powerful argument in a bigger-picture dialog. I wonder if the Ideum method will make it easy repurpose old code which was destined for the web, probably… but your comments hold true - there’s no real innovation if you’re just converting a web/mouse based swf.

As a person holding insider information, I can say that the innovation comes from how gestures are processed and determined.  With the old method, as touchlib requires object extension, it was hard to nest children in a display list in such a way that could adhere to any standard programmatic approaches.  If you wanted an object rotatable and scalable, you used the RotatableScaleable object, if you wanted it rotatable, scalable, and moveable, you use the RotatableScaleableMoveable object (at least initially with internal development).  The GestureWorks method allows you to develop an application without having to worry about modifying those base objects to preform a different type of scale, rotation, etc.  If the formula changes, or even the fundamental application behavior needs adjustment, you would simply either replace the gesture set (used for analysis and packaged as a swc; completely under the developer’s control, programmatically and via xml), or remove the listener that establishes a gesture-object association and replace it with whatever is desired.  While using touchlib, the only solace in modifying a specific aspect of a multi touch enabled application, was to either create a new type of base object, or to modify the existing while hoping it does not change the existing user’s interaction and overall experience.  Most of the hardships I’ve encountered with multi touch programming, is that nothing is automated, yet modular, and that capture layers suck (a non issue now with the sdk).  Every solution has required at least some fundamental knowledge of its existing systems and specifics.  Imagine being able to write the formula for determining a scale gesture in five lines of code, save it, then export a swc that defines your gesture library.  This is what Ideum is providing the community.  It ultimately enables the developer and the overall community, to establish the standards which we adopt over time by providing us with an environment which is familiar, yet highly modular.

that was informative Stat, thanks for that… my interest deepens. looking fwd to it.

Thanks for the insight stats :D. I’m interested in seeing the implementation. With lux approaching soon, which has several changes to the core AS3 API, there could possibly be some fixes for the problems above. There’s no harm in having more libraries that can all benefit from eachother. It would be nice to collaborate on a community based API/sdk though; maybe ideum would see benefits in that.

My only fear is the concept of ‘gestures’ as I think there are various ideas of what ‘gestures’ are and also how coding for multitouch should behave. I think input standardization is good, but I’m not sure one entity should standardize the code methodology this early in the game; just my general thoughts (not geared to ideum directly). At IDC, Jeff Han had mentioned that multitouch to certain degrees is still in it’s infancy and standardizing certain things at this point may be counter productive.

Sorry, kind of got of course there lol. With all that said, I’m excited to try this out; i’m sure it’s well developed and thought out. :D

I totally agree that no one organization should establish the standards that define what a ‘gesture’ is.  Its nice in the sense that GestureWorks is attempting to provide the developer with an object type that essentially encapsulates all information available regarding a touch point (or a hand; directionality and orientation in the near future...) to user defined code for gesture analysis.  A gesture is defined within their gesture api as a set of rules which must be met prior to analysis, so theoretically, a gesture can be whatever you desire so long as it relates to the existing properties provided by tactual objects.

The problems I foresee with this current model is that flash, a scripted language, poses a limitation regarding speed and execution times.  They are working on a c# layer which can be used for any language (provided an sdk becomes avail for that language) as a gesture analysis layer...it will be interesting to see how well that works dependent upon their selected communication layer; hopefully an open com api heh…

From what I’ve seen thus far, I can defiantly say that, in our infancy, it works well while attempting to help establish a way of doing things… The version I’ve received has a locked down gesture library and input provider, in this case, FLOSC TUIO, but I believe the beta release will be entirely modular.

Good news!
It is nice to see this different approach, can’t wait to test it....
since we are also developing another AS3 MT framework.

So Seth you were talkin about RotateScaleMove : Is it a new class , the class i have is named RotatableScalabe

May be it isnt the scope of this thread but does any one have a class wich permit to add physic effect such as throwing photo??

The GestureWorks sdk has a built in physics layer which can be turned on or off per object.  Let me pull the xml settings which define how physics objects can behave.  An internal developer showed me exactly what you are looking for, a media viewer that automatically responds to gesture release events that apply friction to objects.

<application>



        ...



  <touchPhysics>

    <prepos>0.1</prepos>

    <preang>0.1</preang>

    <presca>0.01</presca>



    <velocity>false</velocity>

    <friction>true</friction>

    <gravity>false</gravity>

    <boundary>false</boundary>


        
    <surfric>0.95</surfric>

    <ebound>0.98</ebound>

    <gtheta>0</gtheta>

  </touchPhysics>



        ...



</application>

Is it easy to replace classic TUIO AS library by this one??

this sounds very similar to the approach PQLabs took with their SDK.

hmm… this is what i want for wpf/c#.... is it open-source? i know windows has the Manipulation but its still in its beta

yea is this going to be open source?

By the way, this was officially released a few hours ago… you can go download the alpha version… I noticed it runs only for 1 hour as it’s a trial, biiiig bummer. Don’t things like time trials/nag screens exist when there is a retail purchasable version of the product available? I haven’t done anything with it yet, downloading .Net (which it requires) now…