Midi SysClock is not sent to attached external devices

[gitnob]

In the old stable release of zynthian I could choose bridged midi mode. It was able to synchronize zynthian by an external midi device and send this sysclock signal further to other external devices.

Now on the freshly updated oram release, I cannot figure out how this should work.

I set tempo sync to external, made a midi chain and sent some midi information to an external device.
But no midi clock signal is sent to the external device.

In midi log I can see the sysclock coming in into zynthian from the external device, also I see that the step sequencer is sending it (because it is synchronized to it).
But no external device, to which I send midi, is receiving the clock signal.

Can anybody confirm this behaviour?

Together with Midi Mangling for "All Channels" choice on pure midi chain - #2 by riban it seems as if zynmidirouter has some issues?

[jofemodo]

Hi @gitnob !

You can send the internal zynthian clock by selecting “Internal/Send” in the clock source selector.

In the other hand, i don’t think passing-thru the external MIDI clock like you suggest is a good idea. You would accumulate delay on each device. So the last device in the chain will accumulate all latency from the devices behind. You should send the sync signal so it reaches all devices simultaneously.

To put some numbers, for instance:

• At 60BPM, MIDI clock signal has a period of 1000/24 = 41.66ms
• At 120 BPM, MIDI clock signal has a period of 500/24 = 20.83ms

If you pass this MIDI signal thru the zynthian, it will delay the signal, at least, 10ms, so you will be out of phase by 25% (60BPM) or 50% (120 BPM)! Of course, perhaps this is not important for you. It depends a lot of how you use MIDI clock.

Regarding your request, have you created a MIDI chain to pass the MIDI input to the devices you want?
In ORAM, MIDI output devices don’t receive anything that is not routed explicitly. If you want to pass MIDI clock, you must create a MIDI “thru” chain, choose the input device and the output devices.

Regards,

[gitnob]

@jofemodo,
first of all a big thank you for all your efforts. I am really appreciating this extra work you do (and other zynthianies, too).

Ok, I understand the delay when zynthian is handling the midi events. That’s a pity, though. This also appears on other midi mangling circumstances (for example transposing). The note OnOffs are also delayed then if they are transported to external devices, are’t they?

Without the ability to get zynthian to send the external sync clock signal to external devices, I must build a parallel midi chain for other hardware instruments then.

Unfortunately, zynthian - for me - looses a bit of being a central device now.
For example, vector synth lives from getting the midi clock signal for it’s sound creation and internal delay synching. In my hardware setup, which was based on the old stable release, I was using an external keyboard and sequencer to send notes, CCs and chords, and sync clock via zynthian’s bridged midi possibility - getting back the audio signal into zynthian. Now I have to make a parallel midi wiring to clock sync vector synth, the modular etc., this is suboptimal.

Regarding your question, yes I made a midi chain: midi in is external device, midi out is external other device, but no clock signal was passed through, allthough midi log on the step sequencer shows it. Again, by bridging it was possible in the old stable.

Suggestion: perhaps there could be an option which is off by default, which allows that the clock signal, which is used internally is send to (specific) external devices. Could be a device specific option. This way, only clock is sent if you really needed it.

To your calculation ( ): All in all it’s a 10ms delay, independant from the bpm you choose. If I calculate correctly it would be little bit more than 30% of a 1/64 note length at 120 bpm 4/4 . (500ms 1/4, 250ms 1/8, 125ms 1/16, 62.5ms 1/32, 31.25ms 1/64). It raises to more than 50% of a 1/64 when 240bpm - or am I doing something wrong? This is why under some circumstances you must delay some audio for some ms to sync it.

Regards

[jofemodo]

@gitnob

The note OnOffs are also delayed then if they are transported to external devices, are’t they?

Yes. All MIDI processing devices, not only zynthian, have some latency. You can’t process MIDI without adding some latency. Currently, zynthian with its default configuration has a latency of about 10ms. You can reduce this latency by using a smaller buffer size or increasing the sample frequency. We plan to add easy configuration of latency in a future version. Until then, you can adjust latency by modifying the jackd command line parameters, from webconf’s audio config screen. This has been explained several times in recent threads:

Latency in Oram Bookworm: fresh measurements!

I’ve been measuring latency in the new Bookworm Oram SD image. The audio was configured at 48KHz with 2 x buffers of 256 frames, what gives an internal latency of 10.66 ms. EDIT: this is the detailed jackd config: /usr/bin/jackd -P 70 -t 2000 -s -d alsa -d hw:sndrpihifiberry -S -r 48000 -p 256 -n 2 -X raw I’ve measured the real audio latency. I mean, the delay a signal suffers between the zynthian’s audio input and audio output connectors. In other words, i’m recording simultaneously the si…

@gitnob

Without the ability to get zynthian to send the external sync clock signal to external devices, I must build a parallel midi chain for other hardware instruments then.

I didn’t say this. You can send MIDI clock from zynthian. I just fixed an issue that was causing the filtering of MIDI system messages, and it’s solved now. So please, update and try again. You must create a MIDI chain with no effects, what acts as a MIDI thru. Then select the MIDI input device sending the clock and the MIDI output devices that will receive it.

The same MIDI chain can be used for sending the internal MIDI clock if you select “Internal/Send” as “Clock Source”.

@gitnob

To your calculation ( ): All in all it’s a 10ms delay, independant from the bpm you choose. If I calculate correctly it would be little bit more than 30% of a 1/64 note length at 120 bpm 4/4 . (500ms 1/4, 250ms 1/8, 125ms 1/16, 62.5ms 1/32, 31.25ms 1/64). It raises to more than 50% of a 1/64 when 240bpm - or am I doing something wrong? This is why under some circumstances you must delay some audio for some ms to sync it.

MIDI clock is 24 ppqn (pulses per quarter note). On every pass-thru device, this clock signal is delayed by a fixed offset, that is the MIDI-round-trip latency. Each device in the chain adds its own latency, so the last device see the clock delayed by the sum of delays accumulated. This is sub-optimal but can be enough, depending of how you use it.
Ideally you should route your master clock in a way that it’s received simultaneously by each device, If you are super-picky a star-topology with equal length cables is the best, but using physical MIDI thru is a very good option too, or a MIDI-network protocol like QMidiNet or RTPMidi with dedicated wire, if your devices support it.

The best!

[gitnob]

@jofemodo, you’re my hero of the day. Just tested it and it works like I expect it to work.

Regarding latency: I am absolutely aware of latency, especially because I’ve a mix-up of analog/digital systems. Always following discussions in the forum, especially ATM of the advent of a new release, and because I’m actually switching to oram. Thanks again…

I just saw the 2 patches on github on zynmidirouter’s code about two of my issues I had, “All channels” and system messages… Very nice. I like zynthian and its community more and more.

Hearts and regards

[jofemodo]

@gitnob

Regarding latency: I am absolutely aware of latency, especially because I’ve a mix-up of analog/digital systems. Always following discussions in the forum, especially ATM of the advent of a new release, and because I’m actually switching to oram. Thanks again…

I noted you are quite active in the last weeks, mate!!
Anyway, if not constrained by time (like today) i don’t mind to be more explicit than needed. Think that our conversation perhaps would be read in the future by someone that would find useful the over-explanation.

@gitnob

I just saw the 2 patches on github on zynmidirouter’s code about two of my issues I had, “All channels” and system messages… Very nice. I like zynthian and its community more and more.

Your words feed my soul, @gitnob !!

Enjoy … and send some noise!!! Come on!!!