The first issue seems to be new. We’ll investigate.
The second part however is working as intended. You are using the time:frame notation, which means that the number before the colon : is the second, and the number after it is the frame number. Also, since the time:frame in the timebar goes from 0:06 to 1:00, I assume you are working with an animation that is set to 7 frames per second.
When you type 0:045, you are going to second 0, frame 45. Since you are using 7 frames per second, 45 is the 3rd frame after the 6th second (6 seconds x 7 frames per second + 3 frames = 0 seconds + 45 frames).
You can press R to switch between Move and Rotate while in the Animation Editor, so switching tools should still be possible while the actual GUI button does not work, unless the hotkeys are also broken.
Thanks for your response, I understand the frame notation now - but would you not agree this notation seems arbitrary and a bit confusing? To someone who is a programmer, trying to dip their feet outside for a few minutes when I see something in the notation of X:XX I would assume its a reference to a time value.
I’m also not sure if this is just a fault on your system, or again I’m not experienced enough with using the tool but trying to make it so its “10 frames per second” is also posing as challenge. My current problem scenario actually was trying to make it so for example an animation that takes 1 second overall could have frames at points different to the draggable amounts (as it snaps to the nearest frame) - I presumed then by keying in what I would presumed is standard time notation of H:MM would have fixed this.
Now upon further inspection of the situation I can see their is a settings menu which does answer these questions:
But why is it tucked away in the corner and in what I would say is a non-standard position which in comparison to the UI itself is tiny - my eyes actually brushed over this until today. Whilst it is referenced in the documentation (which I didn’t think I would need to read for a simple enough application) it is unclear to the eye by default. Could I perhaps suggest its moved or referenced into the “…” menu here:
This would then be more inline with the convention of most software (key functions on the top left). Not to mention it is just a menu like the one we see here, and as such it would probably make sense for their to be a settings tab which opens up.
The time:frame notation is standard in animation, especially for keyframe animations. The time part, in seconds, is obvious. However, the frame counter is mostly related to the fact that standard framerates (24, 30, 60 fps…) are not exact divisors of a second, and if we were to use “metric time”, then in 24fps for instance, the timestamps of the first frames would be 0.0, 0.0416..., 0.0833..., 0.125, … rather than 0:0, 0:1, 0:2, 0:3, etc… The latter is much easier to use.
Thanks for your feedback regarding the framerate menu option. We’ll discuss that with our design team.
We have found that the issue you reported about the tools was related to a property of the Workspace. We have not fully determined the root cause yet, but as a workaround, if you change the Workspace.SignalBehavior property from Deferred to Default the tools should work as expected.
Please let us know if you still have issues after changing that.
We’ll keep working on this bug and will let you know when we have a fix. Thanks for your patience!
