Comments (20)
it would be great if you could prepare a minimal demo based on your code, which includes the handling of TUIO11 cursors, objects and blobs.
The original Tuio.js library had a couple demos that should still work, but I need to clean them up a bit. But will do.
from reactivision.
OK, I already integrated the WebSocket code into the TUIO11 and TUIO20 libraries. I guess it would be great to add some browser examples to test everything. I'd suggest to implement a console TuioDump and graphical TuioDemo example, just like for the other environments. In any case this issue should go to the according TUIO repositories ...
from reactivision.
But the Reactivision codebase doesn't actually contain the WebSocket class, right? It's only part of the TUIO reference implementation right now - I was assuming that Reactivision could open a listening WebSocket by default and wait for incoming connections, parallel to the standard UDP transport.
from reactivision.
Yes, reacTIVision is still cooking its own TUIO messages without using the actual library. But I will start with the integration of the TUIO11 or TUIO20 libraries now, although I am not decided yet which I should use. TUIO11 would allow testing within many existing environments, but TUIO20 would allow the integration and implementation of many new features, and the stabilization of the library in an actual test case .... but maybe I should solve the dilemma by integrating TUIO11 backward compatibility into the TUIO20 code, or just create a simple conversion tool for that ... mmmh
from reactivision.
Ah, now I see. In this case, I would also suggest to switch to TUIO 2 for the next rTV release, and perhaps add a conversion tool?
from reactivision.
In both cases I'll need to reorganize the current code base substantially, so integrating TUIO11 for an intermediate 1.6 release would allow me the proper testing of everything in a stable environment, while directly jumping to TUIO20 would make that difficult for the time being. The intermediate reorganization will allow a rather quick switch to the TUIO20 code for a following 2.0 release, which may need a longer development phase anyway, since it requires the implementation of several new tracking features.
The reorganization mostly applies to the acquisition layer (portvideo) as well as the transport layer (TUIO) and some other improvements such as a better calibration and the integration of filters.
The new tracking features will concentrate on the possibility of using various fiducial types such as the current amoebas and my new yamarashi symbols as well as the integration of other types such as QR codes or an implementation of the MS byte tags for example. This kind of feature will definitely require TUIO20 already, so a switch will be necessary at this point. Also the additional contour tracking of untagged objects will not only require TUIO20 but also involve the implementation of a better threshold algorithm, which may result to be a tricky task.
From this perspective the intermediate 1.6 release based on TUIO11 still makes sense, since all those intermediate steps are anyway necessary towards the 2.0 release, and should keep things more stable on the way.
from reactivision.
👍 sounds very sensible, as the APIs of TUIO 1.1 and 2.0 are not that different.
from reactivision.
I'd like to know what the current status of the development is. I have difficulties with the realization of a multitouch table web application on a OS X main computer connected via wifi and hdmi with a Sur40 with Linux (which is the touch input device and main screen) and reacTIVision because I don't know yet how to get touch events into my browser (on my OS X). I already tried npTuioClient which was promising but it was not possible for me to get proper html5 touch events for any interaction (touch, drag etc.) For instance like in D3.js. So the next reasonable step would be the usage of websockets?
from reactivision.
with the integration of the TUIO11 library, the WebSocket support is now also available from within reacTIVision. It can be configured by changing the according type tag in reacTIVision.xml:
This still needs the according implementation and testing on the web client side ... anyone?
from reactivision.
@nomve has most of the client-side implementation done in https://github.com/nomve/Tuio.js - EDIT: corrected link.
from reactivision.
OK that's great, I will have a look at it. Should be a good starting point for the TUIO/Web client implementation. Maybe you could give it a try too, checking out the latest reacTIVision 1.6 from master.
Things are wrapping up nicely now, under Linux the most significant improvements are already working.
from reactivision.
Hi,
I can confirm it's generally working, but I haven't used it too much (mostly because of #13). Maybe worth noting is that there can be only one source; I tried just adding <tuio type="web" port="3334">
to the config, and it didn't work before I deleted the udp entry.
edit: I've already used it a bit more with the Tuio2Simulator and didn't notice any issues either.
from reactivision.
Thanks for testing this Goran! Yes, at the moment it is only possible to select one TUIO transport at once, but I will add multiple transport options asap. This is now just a configuration issue, since the TuioServer already support multiple transport alternatives.
from reactivision.
OK, I added the possibility for multiple TUIO transport configurations with the last commit,
let me know if my comment on #13 solved your camera configuration problem ...
from reactivision.
Thanks again. I'll report any issues if I run into them, but in general the WebSocket connection works fine.
from reactivision.
OK, then I will close this issue for now ... it would be great if you could prepare a minimal demo based on your code, which includes the handling of TUIO11 cursors, objects and blobs. I'd be glad to include this into the official collection of TUIO11 reference implementations. thanks, Martin
from reactivision.
I tried to add this to my reacTIVision.xml
:
<tuio type="web" port="3334">
or also <tuio type="web" host="127.0.0.1" port="3334">
, but I don't get a message via websocket.
I tried to inspect with WireShark and I see that there are some things being sent around:
But the port seems to be unreachable...
Source: 127.0.0.1 Destination: 127.0.0.1 Protocol: ICMP Length: 60 Info: Destination unreachable (Port unreachable)
I also tried other ports like 6050, but no change...
Any idea why this is happening?
(I know this is quite an old repo and and old issue, nonetheless, somebody might be able to help out?)
In WireShark I see that there is still a UDP message sent out on port 3334. Should this not stop if I change the tuio config in the xml to web
?
from reactivision.
What OS are you working on?
Are you using the released 1.5.1 or did you compile from scratch the 1.6 (still under development)?
from reactivision.
Mac OS X 13.3
I am using the release, cause I did not want to dive into how I can build 1.6. If there was an easy guide I can also build 1.6 with xcode...
from reactivision.
I think (but I am just a random guy using this software) that websocket support is not present in 1.5.1.
I usually work on Arch Linux and Windows 10. In both OS I tried 1.5.1 and I compiled 1.6 from source code.
In 1.5.1 only UDP, in 1.6 I found websocket too.
Since I actually needed websocket in 1.5.1 too, I had to employ a node server to receive UDP traffic and send it to a websocket.
Maybe I'm missing something but this is my experience
from reactivision.
Related Issues (20)
- reactivision and pc webcam HOT 10
- SDLInterface not available HOT 2
- feature request: Multi Camera input HOT 3
- Low fps on Raspberry Pi HOT 2
- No object in Pure Data No connect no data HOT 2
- reactivision+Tuio with Processing.org HOT 1
- SUR40 and Windows HOT 2
- OSC structure unknown HOT 1
- SUR40 and Windows10 HOT 3
- mini set not working with reactivision 1.5 ? HOT 2
- Visual Studio 2017 support HOT 1
- DoublePoint type define wrong ? HOT 1
- Yamaarashi symbols giving 0, 0 coordinates HOT 2
- No camera found on SUR40 with Ubuntu 20.04 HOT 3
- ReacTIvision not working because of Tangible Interaction Framework HOT 1
- how to compile without xcode ? HOT 1
- Custom fiducial markers? HOT 2
- Problems with external webcam
- Support for GS camera on raspberry pi HOT 4
- Can not run version 1.6 in xcode
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from reactivision.