Midi Handling

Using Zynthian
1

I’m in the middle of an appraisal of my current set up and have a few Zynthian midi handling questions.

External clock - is it possible to choose (or filter the unwanted) external clock source used by Zynthian?

I’m using a controller keyboard (with master clock) connected to Zynthian via usb, and currently have a second USB synth connected, which receives clock (for arps, bpm delays, etc) through Zynthian. I don’t appear to be able to turn off transmitted clock from this, so Zynthian is receiving 2 clock signals. If I set the tempo to 120bpm on the keyboard, the tempo in Zynthian is 240bpm.
I’ve tried deselecting the 2nd device from any chain inputs, but this doesn’t affect the clock (I don’t think it should anyway)

System Realtime - Transport
I can see in webconf this is an option to enable, and recall from another thread that it may only effective be when Zynthian clock is Internal, but I’m not 100% what it does.
Does it enable the transmit of midi Sysex ‘start/stop/continue’ messages when buttons on the Zynthian are pressed?

I only have a touch screen + external controller, and at last attempt didn’t have any joy starting playback of external devices, but could have another go if I had a better idea of what I was looking for.
On the same subject, could this work with an external clock source, and/or could the start/stop midi messages be triggered via CUIA. e.g Master keyboard with clock source and transport controls configured to trigger CUIA start/stop function as per the Korg NanoKontrol2 control device, but Zynthian also sends out the corresponding system realtime start/stop midi message (to start a external hardware sequencer or drum machine for example) - I have attempted to do this within a ctrldev driver, but not been successful so far. (Not sure if that’s down to my poor coding or the way sysex might be implemented)
Alternatively, could Zynthian be configured to respond to start/stop system realtime? (even if it is just within a ctrldev driver)

Midi Chains - A little while ago there was mention in a thread (regarding a Mackie control driver), about possible changes to chain handling, it was implied that the changes may include some midi control i.e. volume from the mixer screen, I was curious if this still an intended future feature?

Apologies if any of these are explained in the documentation/elsewhere on the forum which I’ve missed.

2

After posting this I typically found some older forum posts which described expected behaviour!

So, multiple clock sources do sum currently sum together, and this is currently as intended?

Zynthian should already respond to system realtime messages (Midi Start/Continue)? Is this what the webconf check box enables or is it on all the time and this just affects the midi log page?

It was back in February this year when I was originally playing around with this, based on some of the dates this should have worked back then, but I may have missed something. I think I’ll revisit this, but a bit of clarification would be very much appreciated.
I’m still not sure under what circumstances system realtime midi is recieved/transmitted and what effect selecting internal/external clock has on this.

3

First check the ZynSeq documentation in the wiki, particularly the section on Timebase.

The timing, clocks, sync, etc. within zynthian is suboptimal. This is a deceptively complex subject which we have started to address but it needs a lot more effort to implement a consistent and robust solution. Currently zynthian has the concept of an internal (MIDI) clock which only runs when a clock/transport client is running. By this, I mean that the sequencer or MIDI player or MIDI recorder is running. This is not ideal and causes some confusion and can break some workflows. Understanding that the internal clock only runs under these conditions helps to plan your workflow, e.g. if you need a continuously running clock, you should start a looping (but maybe empty) sequence.

On the tempo page, you can chose the source of the clock that drives some zynthian modules, such as the sequencer. This may be:

  • Internal - The sequencer acts as the clock, so clock is running when sequence is running and BPM parameter controls clock rate.
  • Internal send - Same as Internal but MIDI clock is sent to MIDI outputs, not just internal modules.
  • MIDI - Use external MIDI clock to drive internal modules, such as sequencer.
  • Analogue - Use a GPI pin as a clock signal (similar to DIN Clock) for internal modules.

Of course things are not simple. There is the concept of multiple external clocks feeding zynthian, zynthian feeding multiple outputs, various internal modules with varying clocking requirements, e.g. LV2 plugins, sequencer, etc. And all of this only relates to the clock, which one might argue should be running continuously - although some devices use absence of clock for a kind of transport control. MIDI clock is represented by a MIDI command 0xF8 that is sent 24 times per quarter note.

Transport control is a seperate thing. The concept is that a device is in a state: stopped, running, etc. There are MIDI commands for Start (0xFA), Stop (0xFC) and Continue (0xFB). When Internal Send is selected, zynthian sends a start command when the transport is started, e.g. the first sequence is started, a stop command when the transport stops, e.g. when the last sequence stops and a continue command at each sync point / bar boundary. Note that these are not sysex commands. They are standard, MIDI realtime messages. I don’t think we implement DIN Sync, but that could be something we consider for better integration with analogue kit, like modular synths.

Song position is another consideration. The concept of knowning the absolute position within a composition. I am fairly sure that we don’t send song position (0xF2) which is an indication of the quantity of MIDI beats (6 clock cycles) from the start of a song. It is something that could be implemented but relies on a robust song arranger, something we don’t yet have. (The arranger is not fully operational.) There is also MIDI Timecode (0xF1) that, similar to SMPTE timecode used in tape and video, provides real time info. We don’t implement this.

Much of the above is background info and not direct answers to your questions.

I though it worked like this:

  • With “Internal Send” selected for Clock Source, MIDI clock should be sent to external MIDI devices.
  • With “Enable System Messages (Transport)” enabled in webconf, MIDI Start, Stop & Continue messages shoudl be sent to external MIDI devices.

…but in fact, the webconf option disables all realtime messages, including MIDI clock and the tempo page “Internal” mode does not send MIDI clock but does send transport messages. This could be improved.

There are some challenges here. What do you want to start, stop, continue? Is it one of the many sequences? Is it the MIDI player? If so, what file do you want it to play. Should it drive the MIDI transport or the audio transport?

Hopefully there are some answers in here that can help to inform your further questions.

4 Likes
4

Thanks @riban, that’s all really useful. I’ll revisit my set-up and see what works for me.

It’s helpful to know that not everything is quite working as expected and there’s room for improvement.

That’s a really good point, and a slightly tricky one to answer from an informed position as part of the reason for asking the question is so I can start using the various players a bit more.

My gut feeling would be for a mostly transparent solution, which would probably be the most difficult to implement. Maybe ‘Start with Transport’ options or similar for the midi and audio players?
Files should be the whatever has been manually selected or loaded by default by the snapshot (if that’s a thing?)
Possibly a similar option within arranger? but i’ve not used this much tbh.
I’d probably suggest leaving any clip based sequences outside of external transport control, unless something like an exclusive/single pad per group new play mode was feasible?
i.e. A pad in a group could be assigned a ‘start on transport’ mode but only one pad per group.

I’ve not looked into, but am aware of the new Zynbleton dev branch, so appreciate the above ideas may be incompatible with the direction this may go.

5

I think that transport control should not interface with clip launchers. It makes sense to emulate the V5 transport buttons. Maybe there could be an option to choose the behaviour is a user doesn’t want or cannot implement the Alt function.

6

I do think that in the same way that chains can be configured which MIDI inputs they get their data from, it should be configurable which input(s) the MIDI clock comes from, which in its most basic form can include start, stop, continue and song pointer.

Having a “grab everything from every input” approach makes for easy plug and play, but you quickly run into situations where there are two devices generating MIDI clocks. Such is the case when I use Zynthian with my Keystage master keyboard (whose MIDI clock output cannot be disabled) and my sequencer. I’d like to be able to tell Zynthian to ignore any clocks from the keyboard and just read them from the sequencer.

1 Like
7

There is a solution for that! :wink:

8
4 Likes
9

i’m on it

3 Likes
10

Ready! You can update (vangelis branch) and test.

  1. Global MIDI messages flag has been removed from admin menu.

  2. In the Input Device menu, for each input device, there are 2 new flags, signaled by 2 new icons:

    • :clubs: Non Real Time System Messages
    • :stopwatch: System Real Time messages (transport)

zui_midi_in_config
zui_midi_in_config800×480 45.2 KB

By default, all input devices have these 2 flags enabled. Perhaps this could be changed.

zui_midi_in_device_options
zui_midi_in_device_options800×480 29.5 KB

You can check/uncheck these 2 options from the device options submenu (bold-push).

Be warned that changes to these 2 new flags are not saved in snapshots/ZS3s yet.
I will be waiting for your comments to validate this. After validating, i will proceed to include the new flags in the snapshots.

Enjoy,

6 Likes
11

From my point of view this seems to work regarding the realtime messages. Turning either of the two input sources I’m using (DIN MIDI and USB master keyboard) off avoids the “clock chaos” and allows it to sync to the respective device.

Haven’t really tested the non realtime messages, as I don’t think my keyboard nor my sequencer generate those. Possibly song position pointer from the sequencer, but I’m not sure.

One that I noticed now that this is working, is that if I have no pattern selected in Zynseq, start the sequencer, and then attempt to start a pattern, Zynseq seems to wait for start (and/or continue?) before starting to play the pattern. I was expecting it to have registered that start had been sent, and start on the next bar or beat once a pattern was triggered. If I attempt to start Zynseq before the sequencer it works fine; the triggered pattern doesn’t play until I start the sequencer. But I don’t think this has anything to do with the switching arrangement.

1 Like
12

It is worth reading the ZynSeq documentation, including the section on playing a sequence, groups, synchronisation, etc. which describe the concept of sync points. When the transport is running, a sequence will start at the next sync point (which you may consider as a bar boundary). If the transport is not running, e.g. no sequences or MIDI player running, then the first started sequence will start the transport and the sequence will run immediately. This concept keeps all sequences in sync. If you want to start on the next beat (and ignore any idea of bar synchronisation) you could set your bar length to one beat, so that the sync points occur every beat.

2 Likes