Timing woes

[arr28]

In the Java API, MIDI devices handle timing information (in microseconds since the device was opened). The input events can be timestamped and the output events can be queued. The documentation says that this isn't intended for complex re-ordering of events, large delays, etc., but should allow for small adjustments to playback time.

Richard tells me that the MIDI wire protocol is purely real time, so this facility must be implemented by the driver.

In experimentation, I was able to add configurable delay of at least half a second when outputting via the Gervill synth. However, when I was trying to delay a note-off event to be played 100ms after a note-on event (for producing the metronome click), it didn't work.

The infrastructure components don't reliably try to deal with timing information at the moment. Also, if we're using different input and output devices, there's no attempt to do the necessary calculations to adjust for different device opening times.

Need to look at the whole area. (Perhaps we'll just timestamp everything with -1 for "immediate", but I think we might usefully want better control than that.)

[rgefryer]

I think we make everything immediate, except possibly drum tracks, unless the java has real issues keeping up. Otherwise we lose responsiveness to the soloist - we'll commit to some aspect of the accompanyment before hearing something from the soloist that might affect our decision.

[kw217]

+1 to @rgefryer . No sense adding extra delay to the system - we should be as hard-RT as possible.

[arr28]

Yes - but for a drum hit, it would be useful to be able to queue up the note-off event at the same time as you generate the note-on event. At the moment, they seem to cancel each other out and no sound is produced.

[rgefryer]

You should never be sending both together. Any note generator should be taking note length into account and scheduling note-off events with the same care as note-ons.