Revise TicksWithMessages

[sowbug]

I pulled on a thread. I was working on #108 to build the piano roll. I was happy with the v0 results, but doing it right needed a real time system. So I set off to make PerfectTimeUnit live up to its name. Now I have MusicalTime, which has bars/beats/parts/subparts, and seems to be smart enough to convert from samples a.k.a. frames and back.

But while making these changes, I realized that everyone implementing the TicksWithMessages trait is doing the same thing, which is taking the current frame number, converting it into musical time, and then often returning without doing further work because it has already handled that musical time point. This makes sense because the sample rate is typically more granular than MusicalTime (e.g., 120 BPM = 2 beats/second 16 parts/beat 100 subparts/part = only 3,200 slices/second vs 44,100 samples/second). It seems like it would be better to have Orchestrator keep a master MusicalTime, advance it, and call everyone only when it changes.

If we do that, then TicksWithMessages changes from this:

pub trait TicksWithMessages: Resets + Send + std::fmt::Debug {
    type Message;

    fn tick(&mut self, tick_count: usize) -> (Option<Vec<Self::Message>>, usize);
}

to this:

pub trait Controls: Resets + Send + std::fmt::Debug {
    type Message;

    fn update_time(&mut self, time: &Range<MusicalTime>);
    fn work(&mut self) -> (Option<Vec<Self::Message>>);
    fn is_finished(&self) -> bool;
}

Notable changes:

• Name changes to Controls to better match that Controllers do this.
• update_time is now a separate method rather than an argument to tick(). This paves the way for work() to be idempotent (explanation below).
• is_finished() is no longer implied in the tick() return value; rather, it's a separate method, and it no longer tells the exact frame where the entity went from not finished to finished.

The new event loop will batch each method; that is, it'll call update_time() for everyone, then work() for everyone, etc. This new control flow gives us a clear start and finish: update_time() means the loop has begun, and is_finished() means it's ending. We can then allow work() to be called multiple times in a single loop.

Previously, we didn't fully specify how we'd dispatch the Messages that tick() produced. We'd call update() as needed, and if anyone cared about timestamping the messages they received, that was up to them. But it wasn't ever clear whether a message was for the current time slice (because someone else produced it during their tick(), which came after our tick()), or for the next one (because their tick() preceded ours). And things could get tricky if we'd already indicated that we were finished, but then someone else sends a MIDI message to us during that cycle.

Problems:

• LfoController contains an Oscillator that produces control messages. The Oscillator expects to do work every frame. So either we decide that LfoController is also an Instrument (so it implements the Ticks trait and gets called for every frame), or we have LfoController batch-tick its Oscillator each time work() is called. I prefer the second approach because it becomes an implementation detail rather than making LfoController into an odd hybrid, and because the individual tick() calls were going to be a waste anyway, since the whole point of Controls operating on a different time granularity from Ticks was because we were OK with control messages being produced only at MusicalTime granularity.
• Timer wants to operate on units of seconds. If we want to blend into the new world, then we'd convert seconds into MusicalTime and go with that. But we will lose the ability to fire the timer at the exact frame (e.g., 44100 if seconds=1 and sr=44100, since granularity of Controls is only about every 10-15 samples). Alternatives: (1) live with a less-accurate timer, (2) change it to take MusicalTime as its unit of measurement, (3) sneak a frame count into update_time() and indicate in the contract that we might call update_time() twice with the same MusicalTime but a different frame count.

[sowbug]

More thoughts on "sneak a frame count into update_time()": we're allowing Controllers to be owners of Instruments. For it to be as accurate, a Controller needs the same amount of event-loop granularity as an Instrument gets, subject to the observation that "the whole point of Controls operating on a different time granularity from Ticks was because we were OK with control messages being produced only at MusicalTime granularity." Maybe having LfoController also be an Instrument is right after all, though it does start to raise questions whether separating tick() into two kinds was the right thing to do.

Gaah.

[sowbug]

This is done enough for it to stick.