Consider using MIDI-based note durations, timings, rests, delays, etc.

[oubiwann]

Read up on best way to set beat, time sig, play notes by beat, play rests, etc.

[oubiwann]

Maybe the messages for controlling sequences?

• Start/stop/continue
• Song position pointer
• MIDI clocks
• Sequence time base
• Tracking clock ticks
• Bar Marker
• Time Signature (Immediate)
• Tempo

[oubiwann]

My qualms with a MIDI approach to this problem are:

1. timing is critical and we need to have as much consistency and as little overhead as possible, and
2. all operations would have to be translated between Erlang and MIDI

I'd rather just keep everything in Erlang (LFE) the whole time, without the need for the overhead of translation to and from.

That being said, MIDI does have useful and time-worn abstractions for this problem ...

[oubiwann]

The Erlang VM is accurate to the millisecond. In 4/4 time a fast song at say 350 bpm would have the following note durations in any given measure:

• whole note (4 beats) --> 350/60=4/x --> (/ 1 (/ (/ 350 60) 4)) --> 0.69s --> 685.7 ms
• half note (2 beats) --> 342.9 ms
• quarter note (1 beat) --> 171.4 ms
• 8th note --> 85.7 ms
• 16th note --> 42.9 ms
• 32nd note --> 21.5 ms
• 64th note --> 10.7 ms

A 64th note at 350 bpm is insane and probably not something that's going to happen very often, if at all. If it does, then Erlang is probably not the target platform for the developer who needs this capability. That being said, we should test this with actual notes + human ears over time. But we'll need to build something to test, first.

[oubiwann]

Instead of creating separate services for this, with code running in new Erlang processes in this or some other supervision tree, it would be nice to run a timer + queue at the same place where notes are being sent to the system MIDI device.

However ...

As soon as we need to write synchronised timings to multiple devices simultaneously, we need a little separation from timer-and-sender in the same Erlang process. Two instruments on separate devices should be able to play completely in-time with each other, so whatever is keeping time (and tracking beats, time sig, tempo, measures, etc.) should be able to provide clock info fast enough that the multiple devices can play in-time.

However ...

The Erlang NIF doesn't offer any native concurrency support for writing to system MIDI devices, so having a bunch of processes that request timing info from a central source and then send messages themselves doesn't really match up well with the lowest level dependency. It might make more sense to have a single Erlang process that dispatches to system MIDI. If that's the case, then we probably want something like the following:

• for every MIDI device a developer wants to send MIDI data to, create a child process (per MIDI device) under the device manageer supervision tree (as is done now)
• instead of sending directly to the MIDI devices from this child process, though, create Erlang term MIDI messages for notes on/off to a central dispatching process
• the central dispatching process will maintain a queue as well as a clock
• for each message it receives, it will calculate the time at which the note needs to be played, at millisecond resolution, convert it to MIDI wire protocol binary, and schedule note on/off
• pausing or stopping playback will cause the queue reader to stop reading Erlang term messages
• resuming or starting will cause the queue ready to start reading Erlang term messsages

To support this, we would need the following:

• a new gen_server, sibling to the device manager supervision tree
• the ability to receive and process incoming Erlang term MIDI messages concurrently
• a configurable, manageable message queue for the new gen_server
• abstractions for tempo/bpm, time signatures, measures, beats, note/rest durations
• a scheduler

[oubiwann]

Hrm, looks like this analysis ultimately belonged up one level in the ticket hierarchy ;-)

[oubiwann]

With regard to this (comment above):

My qualms with a MIDI approach to this problem are ...

I see now that I didn't fully capture my thinking from last night, 'cause reading it now just makes it sound like I didn't want to do MIDI (and we're doing so much MIDI, what's the problem?)

So:

• To do this part of the system in MIDI (time clocks, etc.) we'd have to implement various level of support for this, in Erlang
• Then we'd have to translated between the Erlang native parts of our system that needed timing info and the MIDI implementation we did in Erlang for all our timing needs ...

Yeah, I think that's enough context :-)