Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

leap external is missing #25

Open
matcham opened this issue Jun 6, 2019 · 7 comments
Open

leap external is missing #25

matcham opened this issue Jun 6, 2019 · 7 comments

Comments

@matcham
Copy link
Collaborator

matcham commented Jun 6, 2019

(in devel branch)
there is a leap.maxhelp file that looks amazing, but there's no leap external.
Could you please compile it and add it to the package ?
thanks

@grrrwaaa
Copy link
Contributor

grrrwaaa commented Jun 6, 2019

Hi,

We're working through the unreleased externals in this package over summer, and should have it released soon.
One complication with the Leap object is that the finger tracking in the V2 SDK ("Orion") is much better, but it is Windows only. The SDKs themselves are VERY different, so it's going to be a bit of work to get it going on both platforms.

Graham

@matcham
Copy link
Collaborator Author

matcham commented Jun 27, 2019

Thanks for your reply
looking forward this release :-)
in the meantime, I'm wondering : wouldn't it be possible to get the tracking data connecting to leap motion websocket thru nodejs in Max ?
this would allow a cross platform and external/SDK-free elegant solution ...

@grrrwaaa
Copy link
Contributor

grrrwaaa commented Jul 1, 2019 via email

@grrrwaaa
Copy link
Contributor

grrrwaaa commented Jul 1, 2019

That said, I think maybe we will look at doing both. The websocket is a lot easier to implement/maintain, and cross-platform as you say; but we'll probably still want an external for the parts that the websocket API can't cover, e.g. the IR camera feeds.

@matcham
Copy link
Collaborator Author

matcham commented Jul 1, 2019

I didn't think about ws.client ... it works very easily, thanks !
BUT : as datas from the leap motion are returned as a serialised dict, each new frame is a new string (max symbol) , and it floods the Max symbol hash table very quickly :-(
(Max memory usage grows up, and after a while, Max becomes less and less responsive)

I now remember that I already encountered this issue a couple of years ago trying to get leap motion data using this technique : https://sites.google.com/a/leapformax.com/tcpigoleap/home
a nodejs script running outside of Max, and sending data to max via udp
Issue with Max hash table reported and discussed here : https://cycling74.com/forums/how-to-avoid-flooding-max-symbol-hash-table/
I finally gave with this solution, because the jstrigger trick was too slow...

here is a simple patch showing that Max quickly eats up more and more RAM while flooding Max hash table :


----------begin_max5_patcher----------
984.3ocuYssjhhCF9Z7oHUt10hDP.28lYd.1mfc5pqHl1NcAILIQa6oq4cey
AraFGTiLfWnTjDxe999OCuOKBtVbfpff+F7efnn2mEE4FxNPT68QvZxgxJhx
sL3KL8hmZTa2wfy8Sy13lPr9k+JAebvmDbsh8CpcJDdQb6v7c0LdEU61KzmC
J1oONJtyNvI0tc.9UIiTcbuaH5xmY7sOJokZ+YGmYDA.kjZuTDa+OY4hXvCs
Ohe+0u0P8qGBma98wzVY8DozMYrcneNal8u4ARJDsV1OgffWB41myuAkZ1dJ
rWBAcdXmlj3vcZt6BtvdAiuHvAOL..xouZfywymldvc.feulpkB.JNNF7EOF
.ef3JFmVJ1w0c0pc4l3d4F7PIg7BOIftt1eMgucXDQontlZfzoLgjp2I4Jf4
TulJAhm.p2pWKpT.FG7ujCfmIpmAZx5JZn7Ct.FtWS744mk3UNyhDrieV58N
Rr7y.HfZpRQ1R+MB3e9lzrNfymOT.lMpF.3DGxxVEf2+ff9FVodwdF80dbzw
3wQYgxS8GemGcRZg+xxApsVuSqE79NunOilJMQY0T4iTty7ryAL.rbA8Ra33
DuGIN83+Sge4YBPYUY8fdzpavxK85ZKOBMgAud7W6IhI3D4atTPyOMUjhrmt
4QygzHjGs4GXFcnOEczGXOBRMgY1zQUcQ8X2IqIMMeLsaVGSOh78hMTE0lut
SnftbeFbbrt7bO1ms+V49AYjoEa2V0KlRlduIbhKj.FUDp2DyF4cDcljFIPA
kBtIrt1X80CObKozwWEqnUN+pU4ATVy7opzleuvlN.d43jAyW9ZdVmBXtLbG
8.kMRi0BnVssuhXGmTa3BeZZjKAcVG+0wCFupVTVwLEnA9RiPpAYoI48YmBu
89QNeHHzxzvK+dv1omsGCbXsXX4iatACbpuip7NkNNE8WbtpJEMz9pdYjJbr
U+4Kx59CtxJgpurI4iTPEeA+SM5NqcIJPCymEpAaXh7YCQ4n6N7vqlzV6aei
FECrwd25bcfcxa2wIJ63+JlUhcxxiaUqQH3SoYJoSy3Da0ScVCxuldY0PkS1
cRNKCPN1WeUmEIjanNcHZxkLpeAG+GI3DTHXNdDH2iaxEkDNaDjj0q6pRZ4X
Hn6jcIJD.gwigjBwUCilBWffD8ILwH4DftaJxP7ArMJ9mKIydftla8jvkgfv
r6DBOgu60R0mEjzzrmJUsOtSnlb7uHbKuXt6VF2eqq+Enjtmcb84tQHRSBZs
I67No+KRbHKE5eTgQvbSIBdYafqQjt5Gre8BUS6mUvUlwreN6+gB1qsd
-----------end_max5_patcher-----------

@grrrwaaa
Copy link
Contributor

grrrwaaa commented Jul 2, 2019

Yowch, yes that's a problem. First solution that comes to mind would be for [ws.client] (and [ws]) to detect any received JSON messages and convert them to Dict by default (and perhaps have a @NODICT attr for anyone wanting raw JSON as before).

There might be a bit more overhead because of the JSON->dict parsing/allocation, but this is surely better than flooding the symbol hashtable as it currently does.

@matcham
Copy link
Collaborator Author

matcham commented Jul 2, 2019

yes, sounds good 👍🏻

BTW, the patch I posted above crashes Max on Mac and windows 32bits (Max7)
(instant crash when instantiating ws.client @PORT 6437)
(I created an issue #26 about that)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants