but both are in separate windows and should be handling the frame rates independently, right???
Maaaaaybe? I'm not too sure about it to say the least. Have you had open the Desktop Video setup window while looking at the issue? It might be that the driver wants to lock down everything to the same framerate. Using their mixers locks everything in the chain to the same framerate, but I don't know if this is transferrable to the desktop video products (I'd assume so since it is the same driver). 30 and 29.97 might be so close that you get partial delivery anyways, but then drops out when out of sync.
Looking at the camera specs, it seems that you should be able to switch both to 1080p 25fps. Can you try that and see if you have the same issue?
Linear -> exponential sounds great (although the nerd in me would love exp f(x) = x^x however useless it would be (disregard this)).
I think I initially assumed the easing would bunch up at where the time was in not set to linear. For instance that it would bunch up at .3 if easing were sat to .3 (VuoCurveEasing_Middle = 0.5), but both makes sense though.
This is where it gets out of hand, but perhaps a 3x2 matrix of options for the in and out easing could work?
in
linear
out
in
linear
out
This way, if both are set to in, the whole duration is calculated with an in-easing. In-linear gives in-easing until the center duration then linear the rest of the way. In-out gives in-out, and out-in gives middle easing and so on. In theory this could be hidden from stuff like the curve node while providing the same function as it currently has through the Vuo_curve function while giving a few extra options for other nodes. I assume that is on a different level of nodes to re-code if implemented though (unless it gets its own call at the bottom of the if-nest in VuoCurve.c; VuoCurveEasing_damnUnappeasableUsers(...)).
(For some of the Intel HDxxxx fixes, I think the solution was to disable the feature with those cards, and just make it default to whatever worked without crashing)
Signal drift, try adjusting the overscan to wrangle it in place for some time (it will still drift after some time though). Most likely something in the chain thinks you're running everything at 30fps when you run it at 29.97 (or the other mismatches). Over the 10 - 20 seconds that .03 leftover adds onto itself, and the box/driver/something don't know what to do when it gets info from the middle of the frame where it expects the beginning, and probably tries to auto adjust to the signal. You shouldn't run them at different framerates though, and it is far from reccommended. Putting a decent scaler in between can also solve this issue.
Can you check if the 30fps camera has a NTSC mode? Or if the PTZ can be run in PAL mode? Which camera models is it? If they both have 24/25fps modes that might also solve it.
