Getting leap motion device tracking data available to cycling 74 max msp.
However, as other solutions to this generic problem are already available let' s add more specifications to the generic problem, so that the resulting system should be :
1 - extremely lightweight, transparent, veryeasy  - to enable users of all kind, the most advanced users could very easy modify the code itself without recompiling.
2 - complete - it enables max to read all the available data possibly also future data that is not being traked right now.
3 - crossplatform (mac-win-linux (for the leapmotion part as there is no max for linux))

following are informations regarding our approach to the descripted problem, see also other approaches to similar problems.

1 - When the leapmotion software is installed in mac, win or linux, a websocket service (rfc6455) gets setup in the host OS to serve JSON data. The websocket runs locally on the port 6437.
-As leapmotion users have enjoyed, webpages in browsers can make use of the leapmotion device; this is accomplished via data retrieval from said websocket, this means that any program running locally can request access to that websocket, just as a webpage does in the browsers.
2 - Cycling 74 Max msp does runtime in javascript (max patch files itself are in JSON), so the JSON parser is obvious well implemented and available natively.
-As web searches (20140310) shows, max does not have an object for receiving data from a webservice (that would be too zealous), plus any implementation would be too fat compared with the nodeJS one, especially in max 5.
-In max, the object [udprecevice] is one of the most easy, fast and stable way to get data from network packets.
3Nodejs is a highly available software execution engine... in this context we can see nodejs as any other modern application environment (.net / py / java / flash moreorless / maxmsp itself if you like, infact you can make a maxpatch that it's a "program" and the max runtime is the "application environment",...). nodejs was choosen because of portability, crossplatform, simplicity, and performances (this application only does networking IO).

THE SOLUTION PIGOLEAP, is made of two pieces.
1 - tcpigolo (the nodejs program to read the data from the leap websocket and relay the data via udp in OSC compatible format).
2 - tcpigola (a predefined max patch that gets the data from tcpigolo)
- enough is enough ... see the 12 lines of code for yourself here
- As you can see it's not like we had to invent anything... we don't even process the data because it already comes out in JSON format from the leap webservice... we just relay data as is.
(no ok we change the word "stablized" to "stab", that's just because otherwise the patch woudn't fit right.. yeah it woudn't be square enough :-).
 -It's is a system of individual patches that show users how to grab data.
- The most minimal version of tcpigola.maxpat, requires only 2 objects in a path, an udpreceive and a message, it already shows all the data coming from the leap.
- Others pathes are included that shows details for real usage.
Please, again, note here that given the requirements, (LEAP DRIVERS, NODEJS+websocket module), the 12 lines of code from tcpigolo.js, sadam.udpreceiverexternal and one tcpigola patch are ALL you need as a minumim.