[fingerpinger] with [matrixctrl] runs slowly on Max 6.1?
Hi!
I just downloaded the Max 6.1 demo and it seems that there's a little glitch when using [fingerpinger] (http://www.anyma.ch/2009/research/multitouch-external-for-maxmsp/) in combination with [matrixctrl] and custom images.
The exact same patcher runs perfectly smoothly on Max 5.1.8, but when run on Max 6.1 [fingerpinger] is about 100ms slower in responding (and the whole patcher runs very very slowly..)
Here's the patcher I'm using (and I've attached the custom images I'm using for [matrixctrl])
(If you don't have [fingerpinger] you can download it from the site above, or, well, you can skip this post :P )
Is anyone experiencing something similar or is it just me? I'd like to get in touch with the folks who wrote [fingerpinger] but I want to make sure it is indeed something between [fingerpinger] and Max 6.1, and not just my computer/set-up/whatever.
Thanks!
Yes! Did you figure out a way to resolve it?
i had a lot of crash with *fingerpinger and* max 6.(0.8 or 1.something, can't remember). I ended making a standalone with max5 that includes fingerpinger and udp communication with max6 !..
Oh dear :/
I'm going to try your udp idea now. Is it straightforward and did you get speedy enough performance?
had no performance speed problem afair. A standalone with only fingerpinger and udpsend is quite lightweight. udpreceive is ok. The process is quite straightforward. If you have multicore processor, several max instances will probably be repartited over several cores, so that might be a plus too.
Though, i must say i am not sure that solution is ideal... Specifically, i'm not sure it will help the latency problem. Maybe also fingerpinger works best since Max 6.1. It's also a bit unclean !...
fwiw, here's the patch that i compiled :
No matter. I got it working with mxj.net.multisend and the performance was still horrible - slow glitchy. A Fingerpinger developer told me that the project is now dead.
i'm not sure what you mean by 'mess up the order of messages'. the order of messages coming from fingerpinger is naturally messed up, since you have first a bang coming out right oulet, then messages coming from the left, bang from right outlet before each frame, and finally right after last frame another bang. But it's not related to the use of udpsend/receive, rather to fingerpinger... or did you mean that it first comes out from both fingerpinger outlets, then only it is sent through udp ?
anyway sad to hear the project is now dead. not very surprising considering changes of os and hardware and considering that this is a hack.