17Sep/1140
Release v0.8
Well it really was about damn time. I finally managed to do an official release. Most of the stuff has already been lying around on svn for quite some time but every time I managed to find some time to work on the library I rather fixed bugs or rewrote some stuff than test and put together a new package <.<
Anyway, here is a short rundown of the changes in this release:
- Merged Fiducial code into TuioManager
- Streamlined Mouse and Windows7 dispatcher System -> TuioClient, MouseTuioAdapter, NativeTuioAdapter extending AbstractTuioAdapter
- Renamed org.tuio.TouchEvent into org.tuio.TuioTouchEvent to solve naming conflicts
- Improved gesture performance by utilizing object recycling
- Added the new property "optional" to GestureSteps
- Improved gestures especially zoom & rotate
- Extended and updated documentation
- Added gesture and fiducial examples to the library package
- Improved usability of OSC classes for non internal means.
- Added actual support for TUIO source messages
- Fixed various bugs and hid some new ones
As you can see the release contains quite some refactoring so I will update the HowTos accordingly in the next few days.
If you have any major problems migrating to the new release please let me know.
September 18th, 2011 - 04:07
done some work on a upper layer to your library just awaiting for reply on a submitted article to make it available on google code.
After modifying it (between now and 2012 February) to make it work in this new version.
If you wish the project name e-mail me and I will provide it, and if you find anything worth adding directly to the library I would be most interested in helping in that.
I will also provide some working demos that can be modified to work as demos for tuio as3
October 6th, 2011 - 07:44
I’m getting this error when compiling
/org/tuio/TuioFiducialEvent.as, Line 6 1172: Definition mx.controls:Button could not be found.
I tried adding the flex sdk but it didn’t help…
Any ideas?
I’m using Flash CS5.5 on Mac.
October 6th, 2011 - 08:15
Well I don’t know how that error disappeared but now I’m getting this error…
/org/tuio/connectors/udp/OSCDatagramSocket.as, Line 15 1017: The definition of base class DatagramSocket was not found.
October 6th, 2011 - 08:21
I changed the UDP connector to TCP and the mx.controls:Button error appeared again…
This is frustrating…
October 6th, 2011 - 12:18
I’m getting the same error with Pier about DatagramSocket
… \src\org\tuio\connectors\udp\OSCDatagramSocket.as(15): col: 41 Error: The definition of base class DatagramSocket was not found.
October 6th, 2011 - 12:49
@Pier: just remove the mx.controls import statement. I have no idea what that is doing in there …
@Pier & Fathah: What tool do you use for your project? What is your Build target (Flash, AIR) and what version? THe UDPConnector will only work/compile in AIR projects targeted at version >= 2.0
October 6th, 2011 - 23:42
Thanks, after watching the code I commented it and it worked fine.
I’m publishing in Flash IDE to flash player 10.2 so I changed the UDP connector to the LCConnector and again, success.
Cheers!
November 9th, 2011 - 11:07
hi, i would like to run 2 visual application on my computer and send them tuio data from ccv. but if i am running flash with your library the port 3333 is occupied and i am not able to listen tuio data in another application (in quartz composer) is possible to resend tuio data to another tuio port in your library?.. or don’t you know if ccv allows me send tuio data to more ports in a same time? thank you in advance! best
November 9th, 2011 - 15:28
I’d suggest using a Tuio Multiplexer like the following two:
http://johannesluderschmidt.de/throng-%E2%80%93-a-multiplexer-for-tuio-messages-and-packets/1102/
http://nuigroup.com/forums/viewthread/8568/
November 17th, 2011 - 18:32
Using this version for a simple implementation, using UDPSocket under Air2.6. I’m generating TUIO events from another app that basically generates two swipes every 5 seconds, and rotates two objects continuously. The swipes are essentially continous touches that occur every 10ms across about 300 pixels…
Here’s the issue:
Things run fine for a while – but at random (sometimes within a minute, sometimes after an hour or two), it looks like the TUIO events are no longer heard anymore. Flash is still running fine, and I can still interact with other animations with mouse events that remain active.
Trying to debug and wanted to know if this was a known bug or if this is new because of something I’m doing wrong. Current plans are to try to catch a disconnect event and report it to the stage to confirm that is the actual cause and then to simply implement a new “connect” if possible. Another option would be to disconnect then reconnect every minute or so. Final option would be to switch over to TCP instead of UDP. Thoughts?
November 17th, 2011 - 19:15
mh I haven’t stumbled upon this problem yet.
Could you try to verify at which point of the message chain the touches get lost?
e.g. by listening to TuioEvents or adding a custom ITuioListener to the TuioClient. You could also try adding a trace statement to the UDPConnector to check whether there are still incoming packets.
UDP normally shouldn’t just loose connection since every sent packet is an independent transaction.
Does restarting the tracker solve the problem or do you have to restart only the air app?
Is the other app also done in flash? If yes you could try using the LCConnector.
November 17th, 2011 - 19:18
I have to restart the air app to recover.
I am presently trying to restart the tracker via a keypress once it fails to see if I can get it to come back without restarting the air app…
More to follow…
November 17th, 2011 - 19:21
The “other app” is not written in Flash. It’s an executable written in C that “spoofs” TUIO events that will eventually come from hardware…
January 5th, 2012 - 19:02
Hi,
not sure if I’m missing something, but I don’t get how I can use mouse clicks instead of TUIO events for testing…
I have to use import org.tuio.windows7.*;, but I have no folder windows7 under tuio…
Cheers, Sonja
January 5th, 2012 - 19:25
Found something:
http://code.google.com/p/tuio-as3/source/browse/trunk/org/tuio/windows7/Windows7TouchToTuioDispatcher.as?r=146
But that’s uing a different version of TuioContainer (10 instead of 11 args, name is missing) and when I add that it’s not working anyway.. does anypone have a sample project?
January 5th, 2012 - 20:40
Mouse -> Tuio now works a little bit different since v0.8
You have to use the org.tuio.adapter.MouseTuioAdapter class. It is used excatly like the TuioClient. So you create an instance of the MouseTuioAdapter and add your TuioManager as a listener via addListener.
For NativeTouches -> Tuio it works in the same way by using org.tuio.adapter.NativeTuioAdapter
I hope that helps. If not, please keep asking
PS: I have just checked and it looks like I haven’t updated the article on that topic in ages. I’ll do that asap, probably this weekend.
January 5th, 2012 - 22:25
I would honestly suggest that you split the MouseTuioAdapter into a Flash Player target version and then the adaptor to create an AIR target version. Under FDT, it simply does not compile with all the references to the AIR only libraries.
January 5th, 2012 - 23:27
Could you maybe post the compile error log so I can have a look at it? thx
February 9th, 2012 - 19:10
Sorry for the long delay in my answer, I didn’t see that you replied. Below is a tabs separated export of the problems view in FDT, simply copy it to a text file and open it with excel or google spreadsheets.
Description Resource Path Location Type
Wrong number of arguments. Expect maximal 11 but have found 14. Found at line 217 column 30. TuioManager.as /libs/tuio-as3-lib/src/org/tuio Unknown Flash Problem
Wrong number of arguments. Expect maximal 11 but have found 14. Found at line 241 column 30. TuioManager.as /libs/tuio-as3-lib/src/org/tuio Unknown Flash Problem
Wrong number of arguments. Expect maximal 11 but have found 14. Found at line 444 column 30. TuioManager.as /libs/tuio-as3-lib/src/org/tuio Unknown Flash Problem
Could not resolve function ‘addItem’ at line 211 column 25. MouseTuioAdapter.as /libs/tuio-as3-lib/src/org/tuio/adapters Unknown Flash Problem
Could not resolve function ‘display’ at line 225 column 24. MouseTuioAdapter.as /libs/tuio-as3-lib/src/org/tuio/adapters Unknown Flash Problem
Variable ‘label’ is not declared. Found ‘label’ at line 235 column 60. MouseTuioAdapter.as /libs/tuio-as3-lib/src/org/tuio/adapters Unknown Flash Problem
Wrong number of arguments. Default constructor doesn’t take any argument but there are 1. Found at line 210 column 35. MouseTuioAdapter.as /libs/tuio-as3-lib/src/org/tuio/adapters Unknown Flash Problem
Could not resolve function ‘addEventListener’ at line 53 column 20. UDPConnector.as /libs/tuio-as3-lib/src/org/tuio/connectors Unknown Flash Problem
Could not resolve function ‘close’ at line 137 column 51. UDPConnector.as /libs/tuio-as3-lib/src/org/tuio/connectors Unknown Flash Problem
Could not resolve function ‘send’ at line 128 column 51. UDPConnector.as /libs/tuio-as3-lib/src/org/tuio/connectors Unknown Flash Problem
Variable ‘connected’ is not declared. Found ‘connected’ at line 128 column 24. UDPConnector.as /libs/tuio-as3-lib/src/org/tuio/connectors Unknown Flash Problem
Variable ‘connected’ is not declared. Found ‘connected’ at line 137 column 24. UDPConnector.as /libs/tuio-as3-lib/src/org/tuio/connectors Unknown Flash Problem
Could not resolve function ‘addEventListener’ at line 30 column 10. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
Could not resolve function ‘addEventListener’ at line 31 column 10. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
Could not resolve function ‘addEventListener’ at line 32 column 10. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
Could not resolve function ‘addEventListener’ at line 33 column 10. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
Could not resolve function ‘addEventListener’ at line 34 column 10. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
Could not resolve function ‘bind’ at line 24 column 18. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
Could not resolve function ‘connect’ at line 25 column 14. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
Could not resolve function ‘dispatchEvent’ at line 38 column 12. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
Could not resolve function ‘receive’ at line 26 column 4. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
Could not resolve type reference to ‘DatagramSocket’ at line 15 column 41. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
Could not resolve type reference to ‘DatagramSocketDataEvent’ at line 37 column 39. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
Could not resolve type reference to ‘flash.events.DatagramSocketDataEvent’ at line 3 column 9. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
Could not resolve type reference to ‘flash.net.DatagramSocket’ at line 7 column 9. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
Variable ‘DatagramSocketDataEvent’ is not declared. Found ‘DatagramSocketDataEvent’ at line 34 column 27. OSCDatagramSocket.as /libs/tuio-as3-lib/src/org/tuio/connectors/udp Unknown Flash Problem
February 11th, 2012 - 16:18
ok this makes things a bit clearer. First remove the UDPConnector from your source since that will only work in AIR and use the TCPConnector or LCConnector. That should remove most of the build errors.
The first few errors in the TuioManager are very strange because they result from a different MouseEvent constructor than in the normal as3 api. Are you by any chance buidling against HaXe or Flash9?
As for the build errors in the MouseTuioAdapter, they are a result of using the ContextMenu. You can simply comment thos lines and it should work.
I will think about making an additional flash version of the library but in most cases you will use air for such projects anyway or simply have to remove some lines from the source to make it work.
February 13th, 2012 - 05:08
Yea I ended up removing those lines indeed. I also went through the code and here and there, there are some unused imports, I removed those too.
As for a separate Flash version, now that the Flash Player has been updated with MouseEvent.RIGHT_CLICK it might not be necessary.
I would not suggest to build your library only targeting AIR, because the alternative ways AS3 can be used in the future. For example, the software that my client built is a C++ compiled application that runs on Windows and it loads an SWF, there is no way to load an executable in their software. Scaleform also does that. I believe that Flash may evolve indeed as a self contained app (à la iOS or Android), but the SWF logic of being embedded into something may still happen in different forms, as Flash is good to build UI and afterwards interact with other processes. My two cents
February 13th, 2012 - 18:55
Hmm I stand corrected, there may be a need for a non AIR version after all, as the check for the target (AIR or SWF) is done at runtime, and not at compile time.
Despite all my complaints, this is an awesome library, it helps greatly!
February 14th, 2012 - 03:13
You have a good point there for a non air version of the library. Actually splitting the code base won’t be an option because that will be a nightmare to maintain but I’ll see what I can do with compile-time constants and providing swc’s for the two targets.
I”m glad to hear that the library is useful to you. If you happen to find any other stuff in the library that bugs you please let me know.
February 14th, 2012 - 20:01
Great work!!!
Thanks for sharing.
Guillermo
February 18th, 2012 - 18:35
About splitting the code, it wouldn’t be such a nightmare. For example, make it target SWF by default, and extend those classes for AIR and override the functions that need the difference.
April 16th, 2012 - 15:40
hi, first of all, thx for ur fantastic work !! I discovered ur librairy last year, and I finally have a great opportunity on a big display, an interactive 4m * 2.5m screen
But :/… I haven’t the same problem of DJ on his post,
sometimes the app looses Tuio signal, and the application doesn’t respond anymore
I’m publishing on Air 3.1 and the app is installed on a PC windows 7 over boosted… a little application application manages Tuio which is in fact dispensed to the installation via a (IR? I’m not sure, this installation is managed by another company) radar based on top of the screen,
so normally, there are two applications running at the same time, the tuio software manager and my .air app…
I’m using UDPConnector(’0.0.0.0′, 3333) as u do in ur Gesture example, but the TuioClient is not created on DocumentClass of the project but on its first child… doest it matter ?
Shall I manage instanciation with a kind of “Singleton” getInstance
and try to check if TuioClient is connected, via UDPConnector, on a EnterFrameEvent
and destroy instance if it doesn’t respond and recalibrate app by setting a new one ?
It’s a kinfd of dirty what I’m talking about, but I do need a solution to test…
If you’ve got the method, I’d like to know it
truly
thx again for ur work
e.
April 16th, 2012 - 17:14
Is your tracker set up to send periodic updates? If so you could try to create an OSCManager and add a TuioCLient to that manually. This would allow you to switch the connector on the OSCManager if you fail to receive the periodic updates after a period of time. This would look somewhat like this:
You can also first try to use “127.0.0.1″ instead of “0.0.0.0″ and see if that works better for you.
I hope that helps.
greets
April 16th, 2012 - 18:39
thx for ur reply, I’m gonna check all this
changing 0.0.0.0 by 127.0.0.1…
if I do that in my .air, my collegue has to do the same in his tracker TUIO system, right ? Right now we’re both on 0.0.0.0
second little question…
I’v done a quick SwipeGesture based on TuioTouchEvent.TOUCH_DOWN and TuioTouchEvent.TOUCH_UP, it works quite well when I swipe one, two objects at the same time
BUT sometimes, the events mix themselves I think, so my coordonates of arriving of the objects on x and y,… and the arriving of a swiped object is not good, it arrives where the other event on another object should do… :/…
so, I’ve put an ‘e.stopParopagation() ‘ on my handleDown and handleUp methods, believing it would fix the problem but it does’t :/….
have an idea ?
cheers
e.
April 16th, 2012 - 22:32
Mh I wouldn’t suggest using 0.0.0.0 as a sending IP anyway since it is actually a special IP which means pretty much “every IP”. Which makes sense for receiving since you don’t have to worry about the PCs IP if you simply want to receive data in a network. If you work in a localhost environment though, I would strongly suggest using 127.0.0.1 for both.
Mh maybe check with the TuioDebug if the cursorIDs don’t swap so you can make sure it isn’t a tracking problem. Could you maybe post the code you used for defining your SwipeGesture?
April 16th, 2012 - 23:34
for the loose of Tuio, I’ve done this :
…
I used your methods closeHandler, ioErrorHandler & securityErrorHandler from OSCDatagramSocket to dispatch a new Event.CLOSE instead of just a trace action.
UDPConnector listens to this event and dispatch an event to my manager where the udpconnector listens to this,
So if it received this, it kills my TuioClient and make a new one…
normally, it should work right ? I’m testing it tomorrow, and we will see also your coments around 127 // 0
for the Swipe :
here comes the class Purchase, a purchase is an object, which has a certain value, u have to swipe to a credit card to earn these points
basic….
the two methods are handleDow and handleUp wich manage the swipe dectection…
all the rest is for the animation of the product, its course on the screen,
if you prefer I send u just the methods, tell me
it works perfectly when u swipe one purchase,
I can also swipe two objects in different direction,
but sometimes, as I telled u, those events and then coordonates mix themselves and an object gets where the other should
thats funky, because I’m trying to be sure to be on the same e.tuioContainer.sessionID
so I don’t know to look for more improvement of the system
I did also test to make my own GestureSequence with ur framework,
it did work the same way, and had the same problem,
I did not use the options ‘!A’, ‘!B’, die, etc, I’ve still not really understand how to use it in all its subtility, but it’s quite impressive, once again, the work u made
I would like to retry on ur framework, but I have to deliver something stable on thursday
so, as my method works and this problem is not present all the swipes and doesn’t break the app…, I would like to finish it like this with the method I give u
if u want to see my try on ur framework I can also post it.
your example is clear, but to abstract for me, if you could make one example on ur svn with a real study case like ur gestureManager (scale, rotate, drag), it would be very pleasant, and I’m not talking only for me, I think
thnk u for the time u spend with those little bugs, I really appreciate this framework and have certainly more project to come with it
here is the simple swipe I made
[mod note: removed code because it was sent per mail]
April 16th, 2012 - 23:50
damned, I’m stupid,
the class broke on da blog,
I send it to ur mail by .zip
April 17th, 2012 - 18:16
127…. didn’t solve the problem, it was worth, it didn’t work at all
…
so for the loosing of the tuio, I’m gonna check, as I mentionned yesterday, closeHandler, ioErrorHandler & securityErrorHandler & events
I gcouldn’t setup this for try today :/… but I would be able to do it on thursday…
ur method is certainly the best, as u know ur framework but I do not unserstand it :/.. to high level for me…
Swipe works well, and sometimes, it mix events and the display of objects are exchanged but it’s ok
.. I gonna accept to read them 
But if you have some solution or advice for me
thx
e.
April 17th, 2012 - 19:46
Hi erik, your swipe handling code looks good so far imho, so the only thing I could think of is, that the tracker switches the sessionIDs of tracked blobs and this results in this wrong behaviour. Could you maybe test your app with another tracker or simulator like TuioSimulator or TuioPad?
What you also can try is to sanity check the event target of the TuioTouchEvent.
Regarding the complexity of my proposed solution: Maybe it helps to keep in mind how the data flows from the tracker through the library to your code:
Tracker -> UDP -> UDPConnector -> OSCManager -> TuioClient -> TuioManager -> your eventhandlers
If you create a TuioClient the OSCManager is created automatically, but you can also create it manually to have more control but you also have to hook them up manually.
So first you have to create a UDPManager which needs the UDPConnector as a parameter.
Then you have to create a TuioClient without giving it a connector and add it as a message listener to the UDPConnector via addMsgListener.
April 18th, 2012 - 12:17
thx, gimmix, 4 ur answers
Swipe : I do not have the problem with tuioPad when debugging
…
…
but I tried also on a personal work of friends who have built their own touchtable (quite a good job) and I have the same problem than on the big interactive wall
so, certainly, I should maybe try to check the event target, but as I put TOUCH_DOWN on the object and the TOUCH_UP on the stage of the object(otherwise my swipe is not running as often as I expect), it’s a bit messy
but as it doesn’t break the app in general, it will stay like this
I will concentrate on the solution u explain on the Tracker -> UDP -> UDPConnector -> OSCManager -> TuioClient -> TuioManager
with a developer friend of mine, I will tell u
and then after this project, I want to re test the swipe using ur GestureStepSequence
…
e.
April 18th, 2012 - 23:33
I have a memory management question for you. The library seems to be creating an instance of a TuioCursor at every touch. Is there a reason why these instances are not cleared from memory? Is there a moment where coming back to that cursor instance is necessary? If I profile my application and touch often, I simply see the TuioCursor count go up, but it’s never cleared… Maybe it would be good if these instances were deleted once the touch is up and therefore not visible anymore? Or is that just created when in debug?
April 18th, 2012 - 23:40
I checked actually, the instance count goes up as well in non debug. It would be nice to handle this and clear the memory
April 19th, 2012 - 00:01
@erik: yeah please keep me posted and if you need any help just ask
@mat: mh well the unused TuioContainers should be removed by the garbage collector at some point since all references are removed if the finger is removed from the tracker. Maybe the use of the tuioClient as a key in some Dictionaries prevents the gc from removing the old objects. I’ll have a closer look at this, thanks for pointing it out.
April 24th, 2012 - 17:18
Indeed, Dictionaries seems to be a cause of memory leak: http://jacksondunstan.com/articles/1380
Thanks for listening!
April 24th, 2012 - 19:50
Thanks for the link.
I’ve already made some changes in the current svn revision. Maybe you could check that out and see if it works better.
We indeed forgot to define the Dictionaries with a weak reference when we changed some stuff from sessionID strings to the actual TuioContainer reference.
May 16th, 2012 - 17:05
Sorry for the delayed answer, but I just checked and indeed, the memory leak is fixed, thanks!