[LOGGED] Value adjust > click + shift goes to 0 or min?
-
Hi,
To adjust decimal of a value, we shift+click and scrolling becomes precise,
Doing the other way around produces a strange result... when I'm clicking then pressing shift value goes to 0 (or min if different than 0)
then I scroll and my original value comes back immediately,( I can adjust from my original value)
but this short moment is scary, giving a glitch of "I lost my value" before getting it back,
and if I release click without scrolling, values stays at 0 or min,
I'm not sur this is. a "normal behavior" isn't it?Bests
-
Thanks for finding this one, I've logged it now. We should have it fixed for the next public release.
Best wishes,
Woland
-
cool thanks,
BTW in lots of software ( let s say Ableton at least) we use backspace after clicking a field to get to default value (pan 50, zoom 100), it can be useful when one "discovers" a new box and need to get back to initial value you don't remember.
then one observation,
shift+Click allows more precision in all contexts BUT izzy map,
in the mapping section when you move a point by clicking then using arrows to adjust it, adding shift doesn't give more precise control but less...
is it made on purpose?Thanks
-
Clicking the arrows moves it 1 pixel there is no smaller movement, when clicking shift plus arrow moves it 10 pixel. This is true when all resolutions match.
Best Michel
-
@bennnid said:
Doing the other way around produces a strange result... when I'm clicking then pressing shift value goes to 0 (or min if different than 0)
This has been fixed in our current internal beta. Thanks for the great find.
Best Wishes,
Mark -
@bennnid said:
in the mapping section when you move a point by clicking then using arrows to adjust it, adding shift doesn't give more precise control but less
This is by design.
First, I would expect for a mapping situation, you would set the resolution of IzzyMap to match the Stage to which it is being rendered, and also that the Stage size would match the resolution of the projector. (E.g., IzzyMap resolution set to 1920x1080, Stage resolution set to 1920x1080, Projector is 1920x1080.)
In this situation, I would argue that there isn't any benefit to moving an IzzyMap point by less than one pixel, given that the projector itself would not show it. Instead, my thinking about this was that you want one-pixel accuracy when moving a point with the arrow keys, and a larger movement when holding the shift key, to allow you to more quickly get the point "in the ballpark" of its desire destination.
I can see the argument that this is an inconsistency in the user interface, but since one item is a numeric value, and the other is a graphic element (a point), I feel that they can be handled differently.
In addition, the shift key has the same result when moving actors in the Scene Editor and Controls in the Control Panel: the shift modifier moves the object a larger amount. In this way, the different handling of the shift key depending on whether or not it is a numeric value or a graphic object is actually consistent.
I'm open to hear your thoughts about what I've said above.
Best Wishes,
Mark -
Thanks for your reply, I still need to get the workflow ;)
BTW I notice the 3.0.7. did this bug management on most part of actors, but calculator actor for ex is still behaving strangely when you:
click value ( without scrolling) then press shift and release shift withouth moving... ( I know its a strange behavior, but though shouldn't output 3307,5 ).
thanks
-
@bennnid said:
but calculator actor for ex is still behaving strangely when you: click value ( without scrolling) then press shift and release shift withouth moving
I just tried this in our internal beta, and I can verify this bug is fixed for the next release.
Best Wishes,
Mark -
@mark thanks a lot yep the bug appears anytime you click then shift( which happens sometime on fine tuning parameters)
all the best, and have a happy new year, full of creativity and meetings on line ;-) ( thanks for sharing those)