Improving timing for music
There has been much discussion in the past about how the audio interface could be made more versatile.

One improvement is in the frequency domain, where the most elaborate (and in my opinion best) solution is #333.

Another improvement that is still left unanswered is the time domain, which is difficult because WASM-4 operates on a tick-basis that is hard to break without also breaking fundamental design decisions.

This is a problem because notes currently need to be aligned to 60th of a second, which greatly limits the BPM choices if you want to stay accurate in tempo. 

## Proposal #1: `timer(fn, ms)`

This would, to the user, be a quite simple API which calls any given function after `ms` milliseconds.
(I briefly mentioned this in [an old issue comment](https://github.com/aduros/wasm4/issues/15#issuecomment-992731940).)

Limiting this to one active timer at once is no problem for this purpose, and would probably greatly simplify implementation.

The `FRAMEBUFFER` buffer and the `GAMEPAD` flags would be the same as on the last `update`, and any changes to `FRAMEBUFFER` or `PALETTE` wouldn't change what's currently on screen (though they would remain in the next `update` when `SYSTEM_PRESERVE_FRAMEBUFFER` is set), meaning no graphical weirdness could happen.

`tone` could remain as-is, still operating on a tick-basis, and calling `tone` again would interrupt any currently playing audio on the given channel.
The timing could either be made to align to ticks, or to be offset to whatever the current offset from the tick "grid" is, it doesn't matter too much since it could be corrected the next tick `update` if needed.

Practically, this could be implemented on another thread that syncs with the thread running `update` using a mutex, or on the same thread if doing some math and syncing is kept well in check.

## Proposal #2: `timer` as a called function

Make a seprate `update` (e.g. `timer`, `sequence`, `tick`) whose interval is configurable through a system flag. This would work similarly to `timer` above both in implementation and usage, but limited to a single timer in the API specification itself.

## Proposal #3: `tone` queue

Another solution to this could be to make a "command queue" for `tone` and make the `duration` argument a 10th or even 100th of a tick to greatly reduce the current temporal error. Weaved in with a System Flag to enable the previously referenced new frequency mode, the flag would also enable this new temporal mode which works on a more precise scale. 

Practically, this could work as a fixed buffer with a size of whatever the chosen divisor is (10, 100, etc.), which is then checked whenever a new sample is to be played (similar to what is already done with attackTime, releaseTime, etc.). Whenever a new tick starts, the last item in the queue would be moved to the front set as the currently playing to prevent misuse.

As an API user, this means you could queue up multiple tones in an `update` that would happen in sequence.

This wouldn't have any performance impact at all on the current WASM-4 runtimes, since they already check a `releaseTime` on each sample iteration (which with this would instead be a time in the tone queue).

## Conclusion

In short:
- Both `timer` proposals either require threading or use of precise timing, but have a very simple API
- The `tone` queue proposal requires a more complex `tone` API with an internal buffer

I'm not sure what's best, but I think it's good to have a discussion about this since having music out of sync is sad :C 