Most animation soft wares use FPS (frames per second) to change animation speed. This is good because most game making soft wares also only use FPS to change animation speed. Unfortunately, aseprite only uses frame duration instead of FPS. This isn’t too big of a problem though since if you want to figure out how many milliseconds is the FPS that you want, you simply need to do this equation: 1000/FPS=Frame Duration(ms). This is why I think aseprite should at least have the option to change it to FPS instead of frame duration.
Previous thread touching on issues related to this: Animated GIF export rounding frame durations - #3 by Treadlight
Github issue for this: Specify frame delays by frame count · Issue #496 · aseprite/aseprite · GitHub
Some questions. These aren’t meant to poke holes in your idea (which is a good one!), but to get some details necessary to even begin thinking about an implementation, as it isn’t as trivial a change as it sounds.
Where would you expect this to be input? Per-frame like durations are, just as an alternative input method to ms? At the start of the document, with all the durations set to the ms equivalent, and working in ms from that point on?
How should framerates that don’t translate cleanly to durations be stored? Durations in Aseprite are stored as integer ms values. Most common framerates do not have integer equivalents (e.g. 30fps is 33.333… ms), so if the FPS is ever converted to ms durations under the hood, the timing of the whole animation will be off quite quickly. To deal with this accurately, Aseprite would need to either change how it deals with durations, or keep track of your desired fps and introduce leap frames to keep the durations on track. But if it does that, then how should this play along with the ability to change durations per-frame?
FWIW, FPS is usually used by timeline-based animation software, while frame-based software like Aseprite use durations, since that makes more sense for that approach. I feel like if this is added, it should be done with the possibility of a future timeline-based UI in mind, with FPS given first-class status in how it’s stored in memory and in .ase files, rather than simply translating things to ms upon input.