External Midi Clock not passed to "channels" 2-16" of chain

I have a quite new Zynthian V4 setup with the newest zynthian software on it.
I am trying to get the midi clock signals from an external source to the different midi synths on different chains to synchronize the sound engines plugged in these chains.
Unfortunately there is no midi clock signals coming out from ZynMidiMixer on output ch1_out to ch15_out (hence midi channel 2 to 16). The only chain which is supported with the clock midi events is ch0_out. Is it by purpose?
I tested it via VNC directly using midisnoop to watch the midi events coming out frfom different ports.
Shouldn’t it be better to have the clock (clock/start/stop/pause) midi events on all outputs of ZynMidiMixer. Or another solution would be to have an extra midi MCLK output with only the clock events on the ZynMidiMixer and then a midi option in the zyn-ui to choose whether to connect the chain with it or not.
At the moment I had to use a manual hack to get it to work :frowning:
Or am I missing something??

I can confirm this behaviour. It is not intentional. I don’t think we intend to send system messages to any chain and the leakage to MIDI channel 1 is a bug.

Clock management is on the roadmap but not yet scheduled for development. We are aware of the requirement to improve this.

2 Likes

Yes! MIDI clock should be removed from ALL ZynMidiRouter output.

I can understand this, but then it is a problem for all clock sync’ed effects (delay, arps, …).
I can understand the problems in not getting ZynSeq using external sync, but there should be IMO an option to use a specific external midi clock.
For example by making an extra output to ZynMidiRouter only for clock messages which are coming from any external device.
But thanks for clearing the issue.

And they say there’s no downside of reporting a bug…

All effects/synths sync from LV2 / jack audio tempo. External clocks would be used for "“kind of slavering” jack audio tempo, that would sync all the others. The problem is that implementing a “kind of slavering” algorithm is not trivial at all and we need some deep focus for doing such a task. Anyway, it will be done sooner than later :ok_hand:

Enjoy!

1 Like

I just found another discussion about exactly this topic from 3 years ago: Synchronise plugin clocks (with JACK transport) · Issue #262 · zynthian/zynthian-issue-tracking · GitHub
Very interesting pro and con discussion, and as I understood there is this incompatibility between jack clock and midi clock (or trying to implement kind of PLL to catch midi clock frequency to drive the jack clock…).
Because I am using zynthian as a synth and fx box and not as a sequencer, I’d need the possibility to sync the internal clock to an external source.
I’ll try to be patient and wait :slight_smile:

3 Likes

Yes, that is the exact thread of interest. A lot of the work is done but we need to find time to plan how to complete it in a zynthanic way. We need to add a MIDI slave option which involves digging out the old (removed) code from zynseq and adding as an option. It may also require some rethinking of how we control the transport in the UI. Currently the transport can be started and stopped by various modules, e.g. SMF (MIDI) player, sequencer.

1 Like

BTW, it’s already fixed in testing:

Chains doesn’t receive MIDI clock anymore.

Regards,

1 Like

I have created a dev branch feature/slave_to_midi_clock which allows the Zynthian step sequencer to run from an external MIDI clock. There are some limitations like the SMF player doesn’t sync and maybe effects may not (I haven’t tested yet). Also switching from MIDI clock to INTERNAL clock whilst a sequence is running has odd behaviour but it would be useful for someone interested in external MIDI clock to give it a bash and let me know of any other issues.

[Edit] Also be aware that feeding multiple MIDI clocks will cause the step sequencer to run fast because it will be clocked by both. This could possibly be used for artistic effect.

3 Likes

1 Like