Maybe we should stop calling note indexes "rows" and "indexes", and just
call them "beats"; if they're stored as an integer, they're in fixed-point. Things
like "note rows per second" are a lot less intuitive than just calling them "beats
per second".
NoteDataUtil::LoadOverlapped) without 4s. Slight change of behavior:
if a hold note overlaps the spot where we want to shift the offset, instead
of leaving the offset where it is for another full four measures, we'll try
to change it again at the next measure change. This reduces the cases
where hold notes can prevent the offset from changing for long periods.
We can actually go much higher; I set this to 1<<30 instead of 1<<31 so
we don't overflow when eg. adding one beat or one measure in some
algorithms.
The advantage of this over "999999" is it won't break if ROWS_PER_BEAT
is changed to a large value.
Also, since this value will typically be much larger than any actual row, it'll
quickly show up any algorithms that aren't iterating properly.
An advantage over older code using 999999 is that we don't have to
manually clamp the value to a reasonable range; FOREACH_NONEMPTY_ROW_IN_TRACK_RANGE,
etc. don't care.
An advantage of this over using -1 as a sentinel is that we don't have to
carefully check and fill in the value in every function using it.
It actually looks like almost all of NoteDataUtil can be done naturally
in fixed-point: instead of passing around floating point, converting it to
fixed point for NoteData indexing, and adding floating-point beat fractions,
just pass around fixed point everywhere, and convert beat fractions to
fixed-point (which probably happens at compile-time)
If TimingData, etc. does the same thing, things will be simpler ...
using them in general over beats: it's more precise (we can tell exactly
how it'll round, and we can compare them without ugly error-margin hacks),
and it's what we need to use them with NoteData.
Glenn Maynard