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)
