Wacom tablet unresponsive/wonky in large patch
I have started using a wacom bamboo tablet in a rather large video performance patch. It sometimes works fine, but sometimes it seems to get sort of clogged up in the pipeline. I'm using it to either scratch video at different magnifications or draw overtop of the video as a mask.
The video continues to run fine (sometimes the tablet seems to drag it down with it though), midi inputs make it in on time..but the tablet will either stop completely or just respond every 5 seconds or so. I have it set to receive the same bangs as my jitter metro but have experienced this with its own separate poll as well
Is there something I can look into for the advanced scheduler settings to make sure it's getting it's proper place in the priority/queue and not being deferred to low priority like it seems to be. It would be nice to give it it's own core to work in, but I don't know if poly~ would be something that would work in this situation. I have the most recent wacom drivers (I assume the CNMAT wacom object just gets it's values from this driver)..although I just updated to one they released in the last week and I'm about to test it.
os x 10.6.3, 8gb ram, macbook pro 2.66 i7, max 5.1.5
edit: for more info..I'm using a qmetro at 16ms and I am using the 'flusheventqueue 1' attribute of the wacom object to keep it open...but it just seems really dead as soon as I turn on my jitter metro
My only partly informed guess is that qmetro will cause the response to lag by definition as it's designed to trigger the low priority thread. Maybe try using metro instead or, maybe, metro->jit.qball - check the qmetro help&or reference for details...
Hah..how i've solved it for now: create a wacom patch that sends everything I need into a udpsend and run that patch separately in max runtime...and then use udp receive in my main patch in regular max and there is 0 lag
We had the same problem with the wacom external : some delay appeared at the oultlet of wacom, and we were using a quite large patch. We tried to use udpsend to run the patch separatly, and it didn't work.
Finally, we just solved our problem by closing the subpatch (particularly the ones with visualization like spectrogram) when using the patch and the delays from the wacom totally disappeared.