Relative speed change. Each positive number doubles the number of Matras per akshara. Negative numbers halve them.

A single Duration unit is equivalent to 1 Akshara. Unlike FMatra and Matra, this is an absolute duration, so it doesn't depend on _nadai or _speed.

This is a fractional Matra. The reason to need a fraction matra is if there are speed changes below, so often this is used to mean toplevel matra, which is to say duration / nadai, in which case it's relative to nadai, not speed. But not always! Sometimes it's used to name a number of Matras where it's assumed they have speed changes to accommodate the fraction.

A matra is an akshara divided by the nadai. It corresponds to a single sollu in first speed, which means the actual duration is dependent on Nadai and Speed.

Matra being integral is important, since together with TempoChange, it can encode the invariant that durations are always a power of two rational, once you multiply out the nadai.

0 means nadai matras per akshara. Positive numbers double that and negative ones halve it.

This could be Duration, but it would make normalizeSpeed tricky.

Drop empty TempoChanges, combine nested ones. Drop empty groups.

Transform only the first Note.

Given a duration, return the speeds of 1 duration notes needed to add up to that duration. Error if the speed went past 4, which means the duration probably isn't binary.

This is an intermediate structure where TempoChange has been flattened out. A flat list is easier to deal with, especially since I need to match and replace sections of notes, which may overlap tempo groups arbitrarily.

However, FGroup is actually nested, not flat. Oops. Originally it was flat too, with a count to indicate the scope, with Tempo in a Meta type. I still needed to express the tempo and group order, so I added a separate FGroup, and then it got complicated to keep the count up to date when the children changed size, and process things recursively and it seemed like recursive data would make that simpler again. I only replace sections of notes within group boundaries, so it doesn't need to be flat like TempoChange does.

It turns out it's still annoying to modify trees though, evidence in cancelKarvai.

Another way to look at this, is that each FNote is one Matra.

Convert events with Tempo into events with absolute positions in State.

I need to look in the group to know what the actual duration is, unfortunately.

Calculate Duration for each note.

TODO this is wrong in general because unfortunately groups can affect duration, as in flatToState. I think I only call it after Koravi.realize, at which point the notes do reflect the duration, but of course that's not reflected in the types. flatDuration has some details.

Convert events with Tempo into events with absolute positions in State.

This is only correct when the group doesn't affect duration. Since there's no group in here, presumably it's already been stripped out, which of you should only have done if it's no longer needed, which is the case post realize.

Normalize to the fastest speed. Fill slower strokes in with rests. Speed 0 always gets at least one Stroke, even if it's not the slowest.

This normalizes speed, not nadai, because Realize.format lays out notation by nadai, not in absolute time.

This is similar to normalizeSpeed, but working on Notes instead of Flats. Expand speed to the given toSpeed, or error if there's a speed above it, or if I run into a nadai change. This will eliminate all Notes.

Keep track of timing and tala position.

Number of aksharas relative to the avartanam.

Absolute number of aksharas from the beginning of the sequence.

Show avartanam, akshara, and matra as avartanam:akshara+n/d.

Flatten the note and return its Duration.

Convert a tempo-relative Matra to a toplevel FMatra, which should only be nadai-relative.

Duration of one matra in the given tempo. This doesn't include _stride, because stride adds matras to the note duration, it doesn't change the duration of a matra itself.