I would very much appreciate it, if it had a damping behaviour as the version by dottore did.
Also: There seems to be a bug in the camera movement. Sometimes the camera gets “stuck/locked” and cannot be moved anymore. A reset resolves this, but sometimes even multiple resets are needed.
this wasn’t easy to fix since the VL Damper doesn’t have a reset pin. however, the Filter node which behaves like a Damper when set to Expo mode now has a reset pin. so this is possible now.
would you keep the 1s long damping time? that always felt a bit slow for my personal taste. currently have it on 0.5s and it feels a bit snappier.
Hi. Great to hear this is being considered. .5s as the standard should be fine, but it needs to be a settable input pin. The bug is hard to reproduce, but I’m still getting it very often. I think it has something to do with window switching, but can’t pin it down yet.
hm, wasn’t able to break the camera. can you describe in more detail? dx9 dx11? windowed, fullscreen, docked? any special mouse settings? test patch would be ace…
The bug just happened again, seems the keyboard state node in VL reports a pressed R key, even if it is not pressed at all.
I can reproduce it now if I switch focus in windows while holding R.
edit: Even after restarting vvvv. just holding R and then clicking on the desktop / focussing another application freezes the keyboard. it feels like after this bug happened once, it happens all the time in different situations, but that’s just hunch.
Regarding your questions:
DX11, windowed, on Renderer and Preview alike.
this helped a lot, thanks for the detailed report. i could improve the behavior a little bit. if you press R again when returning to vvvv the key should be removed again. the core issue, that the keyboard window node doesn’t send a device lost message when switching windows is not yet solved… but now we know.