[Design] Fixed point numbers may be better suited to represent time than f64

[PieterPenninckx]

Currently the MVP Design Doc states:

• "MusicalTime - unit of "musical beats" - internally represented as an f64"
• "Seconds - unit of time in seconds - internally represented as an f64"

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 nan and inf? (i.e.: it doesn't implement Ord)

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 nan etc.

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.

[BillyDM]

I actually have decided to move to fixed point recently, I just haven't updated the design doc yet.

You can see the current progress of the new system here if you wish: MeadowlarkDAW/meadowlark-core-types@632b648