Ability to adjust (pre)delay of MIDI clock

[riban-bw]

Is your feature request related to a problem? Please describe. When synchronising devices with MIDI clock, the receiving device may run slightly behind the sending device.

Describe the solution you'd like It would be advantageous to be able to adjust the send / receive pre-delay so that a receiving device can run in sync with the sender. Being able to adjust both the receive and send timing would allow Zynthian to run in time with other devices no matter their available configuration. It could also help with timing when using Zynthian as a clock / sync converter, e.g. MIDI Clock to 1PPQN.

Describe alternatives you've considered The current MIDI clock timing is quite good so could ignore the delay but it is noticable.

Additional context Delay has been observed by listening tests. It may be advantageous to measure the delay.

[riban-bw]

The delay between metronome clicks on both sender and receiver is approx. 13.8ms when both are running at 44100 samples per second with 2 x 256 frame buffers. The audio delays on both devices should be similar so we can use the time difference as that between the clocks. It approximates to 2 periods. It is plausible that the sender has 1 period delay at the MIDI output and the receiver has 1 period delay at the MIDI input or that the 2 periods correspond to the 2 buffers used by JACK on one of them. The extra 2ms may be attributed to the time it takes to send / receive a MIDI message.

[riban-bw]

The receiver can lock at 1, 2, 3, 4 periods late (6, 12, 18, 22ms). It often plays the metronome click twice on the first loop. This suggests the lock method is inconsistent. This should be fixed before attempts to tune the latency. If we can lock to 1 period (5ms) we may feel this is sufficient.