Currently the MVP Design Doc states:
MusicalTime - unit of "musical beats" - internally represented as an
Seconds - unit of time in seconds - internally represented as an
I have some non-optimal experience using
f64 to represent time:
- In a (not publicly available) software synthesizer, I used an
f32 and later an
f64 to represent the offset in a particular audio file (playing speed was not 100%, but depended on the note being played). I used two counters: one that counted samples (or frames, if you wish) and one that counts "blocks" (groups of samples). Because of rounding errors, the two diverged very quickly, resulting in audible artifacts. It took me quite some time to figure out what was going on. In the end, I used fixed point arithmetic.
- In another project, I used
f64 to represent timestamps. Since
f64 doesn't implement
Ord, I had to do some trickery e.g. for a simple binary search.
In my experience, floating points have the following problems:
- rounding issues
- what to do with
inf? (i.e.: it doesn't implement
How can these be solved when still using floating points?
- rounding issues: be very careful, e.g. do not use two counters, but only one to avoid inconsistency
- use some specialised crate to avoid the possibility of storing
What does fixed point solve?
- Fixed point representation does not really fix rounding issues in all situations, but it forces you to think about it.
- Fixed points implement
Ord, but instead you need to watch out for overflow/underflow
Does fixed point arithmetic introduce new problems?
- Yes: it leads to more complicated code.
Is there anything that fixed point arithmetic does really fix?
- Yes: with fixed point arithmetic,
a + (b + c) = (a + b) + c. This isn't always the case with floating points. I haven't yet encountered a problem where I could pinpoint this floating point behaviour as the cause, but when it does matter, you can be stuck.
All in all, with my experience, using fixed point to represent time would be my first attempt, rather than floating points (even high precision floating points). I think my point is more "Have you considered fixed point representations for time", rather than "Fixed point representations are better."
Note: I'm not suggesting to use fixed point numbers to represent actual audio frames. I'm only talking about time here.