Noticeable delay getting frames from leap motion

Bug Reports
1

Steps causing the bug to occur

  1. Launch the example composition ‘DisplayLeapHand.vuo’
  2. Connect Leap Motion Controller
  3. Run Composition
  4. Visually observe delay in hand motions
  5. Confirm delay by inspecting the output of the ‘hands’ value from the Get Frame Values node while moving hand above leap and removing it.

How did the result differ from what you expected?

There is a delay, ranging from about 1/2 second to several seconds from when my hand moves over the leap controller and when the value of ‘hands’ coming from the Get Frame Values node is updated.
I also tested my leap motion with the ‘Visualizer’ app from leap - it seems to be working fine, no delay.
I tested a composition with less going on - the hand and pointer count - CountLeapObjects.vuo - after I increased the fire periodically rate to .02 there was no noticeable delay from when I moved my hand over the leap and when the console logged it’s presence.
It seems like the delay is happening with compositions that have more complex rendering.
My machine specs:
Mac Book Pro mid 2012 2.6ghz Intel Core i7 with 8gb Ram. NVIDIA GeForce GT 650M 1024 MB graphics card
OS 10.8.5

When did you first notice this bug?

Experimenting with Vuo .0.5.2 today

Have you found a workaround?

not yet

Other notes

  • Vuo version: 0.5.2
  • macOS version: OS X 10.8

DisplayLeapHand.vuo (12.5 KB)

CountLeapObjects_mod.vuo (2.85 KB)

2

Thanks for the report, @gabe. We just noticed that today, too.

It’s related to the graphics performance improvements added in Vuo 0.5.2 — an unfortunate side effect of that change was that if graphics rendering doesn’t keep up with the event source, the events will queue up and get processed later than expected.

We’re working on it now, and it’ll be fixed in the upcoming Vuo 0.5.3 release next week. (And as a temporary workaround until then, you could use Vuo 0.5.1 for interacting with Leap.)

3

Fixed in Vuo 0.5.3.