Try reordering tick()

[sowbug]

Current:

1. Process pending requests
2. Record position (or amplitude, or signal value, or whatever)
3. Update
4. Return position as recorded in step 2

This way lets us configure position externally, then call tick() and get back an unsurprising value. But we have to be careful not to look at the value before tick() or after tick() -- we must squirrel away the value as returned in #4 and be sure to use only that. It's fragile.

Proposal:

1. Skip step 2 if flag set (flag would be something like "we set the position manually" or maybe even clock.was_reset())
2. Update
3. Process pending requests
4. Return position

The advantage of the proposal is it's less sensitive to ordering. Call tick() at the top of the event loop, and then get the current frame's position.

[sowbug]

Saving a comment draft for posterity:

    // The tick() method is in three stages: (1) handle queued events like
    // note-on, note-off, (2) calculate the amplitude for the current time
    // slice, (3) update amplitude and state for the next time slice.
    //
    // We do it this way for two reasons.
    //
    // One, the first tick() should act on the initial envelope parameters,
    // rather than immediately updating before returning the first amplitude
    // value. For example, if we are at time zero, then the first tick() should
    // return the amplitude at time zero, not time zero + delta. That's why the
    // update code is last rather than first.
    //
    // Two, some enqueued events like attack and release should happen
    // immediately, so that there isn't a lag because attack/release affect the
    // delta. That's why they use set_target()'s fast_response parameter, which
    // cheats by applying the just-calculated delta in stage 1.