Using Zynthian 5.1 with external synths, midi chain, clock and transport duplication issues

Using Zynthian
, , ,
1

Hey

I’m currently trying to use Zynthian 5.1 in a hardware midi studio, mostly as a sequencer and controller. I know there’s a few topics covering this scenario but they are dated and non-identical to my use case. I’m running into issues that seem to be bugs - so I’m wondering if I’m using things wrong. So allow me to explain what I have now and what my experiences were so far.

Midi Chain setup

Basically what I did was create a snapshot for my studio, with 7 Midi chains (without any processors) that are configured to send to the DIN Midi out port on a specific channel each (sidenote: a bit annoying you have to enable that output port each time, by default none are enabled, defaulting to the DIN out would make sense to me here).
My Midi keyboard is connected with USB. This works perfectly the way I want it to work: I select the instrument chain I need on the MIX screen and then I can use my midi keyboard to play it. I don’t need to think about channels ever, just select the chain (that I named after the instrument). Perfect.
Later I will add other USB input devices, but I want to keep things simple for now.

Clock Issue - bug

Next my plan was to dive into ZynSeq. I set the “Clock Source’“ to "Internal Send” because I have some vintage devices that just want to get clock (they have their own sequencer). Next I press a pad to trigger play (everything still empty - default). I suddenly get a super rapid continuous burst from my external drum machines. After a look with an external midi monitor, I noticed every single transport (start/stop) message, and also every single Midi Clock Byte, is being sent for each chain. So everything is sent 7 times. 7 times start, 7 times 24 Midi Clock Bytes per quarter note. All on the same DIN output. That is clearly a bug right? I’m 100% sure there is no external midi loop happening. Probably this behavior comes from the fact that internal instrument chains of course do need these things indivudually. But for a MIDI chain routed to external port, that should be different, as clock is a “channel-less” message, every receiver will get it regardless of midi channel.

Anyhow, to continue to at least expore ZynSeq, I set Clock Source to “Internal” again and disabled “Midi System Messages” and ignore the external machines that need sync for now.

Using ZynSeq with Midi Chains

I’m staring at the pad UI and I see each pad has a default midi channel. Ok, fine. I would have preferred it to default the groups to my pre-configured chains but ok. Let’s change a Midi channel then. The ZynSeq User Guide says about Midi channels:

If there is a chain associated with the MIDI channel then the name of the currently selected preset of the chain is displayed in the topbar as MIDI channel is selected.

That’s very convenient, but in case of external Midi that’s not possible. So nothing is displayed. Again, I would have hoped to be able to select from my pre-configured chains and see the names there instead of having to deal with channels again. But, I did managed to make a sequence eventually and drive my external synth without issues.

I just checked with instrument chains it does show the name of the instrument (Dexed in my case) which changes to the actual preset name once I select a preset in Dexed (weird). So the UX there is good.

It appears the usability of Midi Chain functionality could use some work in ZynSeq. Or I’m using external midi functionality completely wrong?

I’m running quite a recent version:

zyncoder: oram (e903d39)
zynthian-ui: oram (f3897cd)
zynthian-sys: oram (6303572)
zynthian-data: oram (37d9261)
zynthian-webconf: oram (024ff8d)

1 Like
2

Hi @rv5! Thanks for the detailed description.

Your set up is interesting. From your description, it sounds like you are using Chain Mode to allow you to use zynthian as a section for which MIDI channel your MIDI input device is routed to, by selecting different chains.

This is not necessarily a bug but certainly looks like undesirable behaviour. I mean that, we may not have considered this workflow and hence have not engineered zynthian to support it. I recommend using webconf’s “Report Issue” button to add a bug report to the issue tracker. Your observed behaviour is plainly undesirable. I anticipate a substantial change required to resolve it but big changs starts with a small request…

That also deserves a feature request within the issue tracker. IIRC the name of the first MIDI instrument using that channel is shown. (There may be several chains with the same MIDI channel.) It could / should use the chain name (which is configurable). (Be aware that this behaviour is due to change in a future release where zynpad is replaced with a more fixed-structure launcher grid, but this behaviour can be improved in both.)

I think the former. It was added and works at a basic level but may not have been used by many people, so your report is very useful to identify areas it can be enhanced.

5 Likes
3

Thanks for your reply.

As requested I have created the 2 issues on github:

1 Like
4

Hi @rv5 !

FIRST SOLUTION

I think you could “kind of solve” the first issue by doing this:

  • Disconnect your current chains outputs from DIN-5.
  • Create a new MIDI chain that receives ALL MIDI channels. Connect this chain’s output to DIN-5.

Previously, you should had enabled the transport messages for the Zynstep from the MIDI input menu. I tested all this in Vangelis, but it should work in Oram Staging too.

Anyway, i’m thinking on a proper fix to avoid message duplication when merging the output from several MIDI chains.

Regards,

1 Like
5

SECOND SOLUTION

A different approach to solve the first issue (MIDI clock duplication):

  • Add a “MIDI event filter” processor to all MIDI chains except one. Configure the filter to block system messages.

Regards,

1 Like
6

The first solution is more simple and efficient, so you should use it unless you need/want to do some MIDI processing in the chains. In such a case, the second solution is the right way.

You could also mix the 2 solutions in imaginative ways :wink:

For instance, imagine you want to add a chorder to chain 3 (MIDI channel 3), then you could setup things like this:

  • Unroute all chains from DIN-5 except chain 3
  • Create a MIDI chain that receives all MIDI channels. Add a MIDI Channel Map processor and configure to ignore MIDI channel 3. Route this chain to DIN-5.
  • Add a “MIDI event filter” processor to chain 3. Configure the filter to block system messages.

Regards,

1 Like
7

Or a Number 51 with egg fried rice, if you’re in the trade. . . .

Flexibility is the gift that keeps giving!

2 Likes
8

Hmm.. that works indeed for clock, but then how is the Midi from the chains getting any where? The whole point of making the Midi chain is to not have to think about Midi channels, as every chain represents an instrument (and I select a chain to play it with the keyboard). With this “solution”, I need to use the midi channels again on my external Midi keyboard and the Midi Instrument chains don’t have any actual use any more.

I now did a variation of the Second Solution: I created a separate channel for the clock (disconnected from my midi kb) and added filters to all the others. Setupwise and esthetically it’s a bit meh but I can at least continue to explore now! Thanks for the help.

Here’s my current mixer screen:

IMG_5661
IMG_56611920×1256 108 KB

3 Likes
9

The main use-case for solution 1 is using the zynthian sequencer. For other use-cases, the second solution (with variations) is the way..

cheers!

1 Like
10

Got it.
I added one more comment to the now-closed github issue, I hope re-opening it can be considered in the future.

Meanwhile I’ll see if I can add some info about this in the docs

1 Like
11

Hi @rv5 !

Fixing the issue “properly” would suppose, more or less, implementing what you are doing by hand, adding the needed config options.

An easy “improvement” would be to remove system messages from MIDI chain’s flow (we could add a flag for this), so you avoid the “MIDI event filter” on each chain. Most of times, chains itself don’t use the MIDI clock or other system messages and you only want they reach the external devices. LV2 plugins have their own way.

I know the current solution for your use-case is not elegant, but it works. What i mean is that current implementation is super-flexible and cover almost all use-cases you can imagine. Implementing your particular use-case in the core would add complexity and potentially could suppose losing some of the current flexibility. Of course, we are open to do it, but not for a single-use case. We would need more users demanding this :wink:

Regards,

2 Likes
12

@riban, i’m thinking, for the future, that MIDI clock and other system messages could be separated in a specific zmop. This would pave the road for a good solution.

1 Like
13

Agreed! We have a long-standing task to rationalise clocks, timings, etc. it keeps getting bumped by other more urgent or interesting tasks.

3 Likes
14

Hi @jofemodo, what is a zmop?

1 Like
15

Well that saved me asking.

2 Likes
16

Zynthian Midi Output Ports??

MIDI Output Ports (ZMOPs)
2 Likes
17

It’s an internal node in the core library code. We have mips and mops, between which we do routing and processing. Nothing for users to be concerned with. Very low level geeky code stuff.

2 Likes
18

can someone grant me access to edit the wiki? I’d love to add some notes where MIDI Chain is documented

1 Like