If I were mixing the two video signals it would make sense that the drop frame and non-drop frame rates would conflict and cause this issue, however I am not. They are in the same composition yes, but both are in separate windows and should be handling the frame rates independently, right??? I've attached a completely stripped down version of the project to eliminate all other possible causes for this issue.
Unfortunately the neither camera can be switched to match the other cameras frame rate.
The width, height and time inputs are not in the order as they are in the subcomp file.
Yes, this is a bug. Thanks for reporting it.
This may be unrelated but…
Could you create a separate bug report and attach the composition? I don't think it's related to this bug.
upon searching it returns pages and pages of links to the manual
We intentionally made manual sections rank higher in search results than bug reports, since the manual is more helpful for people trying to learn Vuo. When you want to search only for bug reports, you can use the "Filter by content type" link in the sidebar.
+1 to Magneson's suggestion. If you can test in some other Blackmagic capture app besides Vuo, even better. That would eliminate one variable.
If for some reason you can't get both cameras working in the same composition, another option would be to have one composition receive from the barcode camera, decode the barcode, and send it to a second composition (via OSC, or by writing text to a file).
Magneson, do I understand correctly that, as the input moves from 0 to 1, you'd like the curve type to change smoothly and gradually from Linear to Exponential / Easing In to Easing Out?
For Linear to Exponential — The formulas being used now include Linear = x, Quadratic = x^2, and Cubic = x^3. So my first thought is to make the new formula x^n, where n is a function of the input value. At 0, it would be x^1 (Linear). At 1, it would be x^10 or something like that. Would that work for you?
For Easing In to Easing Out — Easing In makes your outputs bunched up near the start time, while Easing Out makes them bunched up near the end time. Would halfway between Easing In and Easing Out be no easing (outputs are evenly spaced and not bunched up anywhere)?
I'll borrow the V2 again and try to answer your question about random and missing points this week sometime.
Although NImate is good at what it does it's just a little bit flakey, randomly shuffling it's Syphon outputs is one such annoyance. I'm guessing what you see in your OSC monitor is another example of the flakiness. It would be so much better to have the skeleton tracking done within Vuo.
If I understand correctly from your other posts on the Skeleton Tracking feature request, you will likely not be implementing skeleton tracking from the Kinect, but from regular video cameras using one of the new ML libraries. That'll be great, other cameras are so much more flexible. If it's at least as reliable and accurate as what is currently available it will be a boon! I guess the ML is only going to get better as it is used more and more.
We did a cursory test of NI mate 2.14's "Kinect for Windows 2" sensor. In "Basic" mode (with hands disabled), it outputs the attached 27 points. Not sure why it's excluding Chest and Pelvis and including some fingers, but that would be something we'd need to look at more closely when implementing this. Unless you happen to know.