Splitting keyboard

First of all, thanks for this excellent piece of hardware and software. I can now play the synth AND the guitar (with some delay effects on it) at the same time, or play arpeggios with my foot controller to accompany myself. It’s just insane!

Although, I’m really confused about how to create zones on the keyboard for different layers. I was able to achieve that using multi layer mode, cloning and putting midi key-range filters on each specific layer. However, after a software update this solution just stopped working (I’m using RC3). Now the filter is completely inactive. Why could be that?

Can somebody please explain me what is the proper way to split the keyboard into multiple zones? My ideal use case would be: a layer with a drum machine assigned to pads on my controller, and multiple rhythmic layers using arpeggiators. Is it possible to use multiple arpeggiators on different layers to create polymetric patterns?

Please help, cause I’m stuck. Thanks.

You could use the keyboard split plugin in a MIDI-FX layer. Route your keyboard through this layer and it’s output to the synth layers / arpeggiator, etc.

1 Like

Ok, thank you very much. The splitting works this way, although the plugin splits the keyboard only into two zones, and I need at least three. What is more strange: I can assign various midi effects to these two zones, chords, even midi delay, but the arpeggiator plugin simply doesn’t work this way. I can’t find out why. If I don’t use the splitter, it works again.

You should consider using the zynthian’s native MIDI filter for implementing your MIDI split:


Perhaps this section should be more accessible from the wiki menus :wink:

For instace, you could try something like:

MAP CH#0 NON#0:45 => CH#1 NON#0:45
MAP CH#0 NOFF#0:45 => CH#1 NOFF#0:45
MAP CH#0 NON#72:127 => CH#2 NON#72:127
MAP CH#0 NOFF#72:127 => CH#2 NOFF#72:127

This will split your keyboard, sending the lower notes (until A2 => note 45) to channel 2, and the higher notes (from C5 => note 72) to channel 3.

The note numbering is like that:

being octave 4 the middle scale (A4=440Hz).



Sounds good… Thank you for your reply, I’ll try this one :slight_smile:

I would certainly be beneficial if there would be an easy UI feature on the appropriate level in the routing/layer architecture that would make this very easy: a common use case as usually the number of engines/sound layers outnumbers the number of available keyboards…

Probably an easy way to introduce a 2 way/3 way/4 way/… split and or a custom split at a number of points would help for assymetric splits.

What are people’s ideas and use cases for this? A common implementation on Zynthian should certainly land at the right level in the Ui and allow for most of these before having to resort to a more ‘technical’ solution in the webconfig which would still offer most of the flexibility of course.


I have thought quite a bit about building such a UI for splitting, but i’ve not started because i didn’t perceive enough demand. It would be a pleasure to implement it if there is enough interest :wink:


I think we may have discussed this before and at that time felt this was a feature best located within the controlling keyboard and that there were ways to do it in Zynthian if required.

I would certainly appreciate such a feature.
How do you envision it?

Easy to use :grin:
It would be nice to have the possibility of using keyboard key-presses for configuring the boundaries, as well as the rotaries. I would like to have visual feedback so you can see a mini-keyboard on the zynthian UI with the keyboard zones, etc.
I’m not sure of including a transpose option. It is already implemented on the layer options, but with semitone resolution. Perhaps the splitting UI should include an octave transposing.



We would benefit from the ability to define controller models, because there are many, many devices that are getting connected and not all of them have such concepts as keyboard splits.

Ideally we would have ‘drivers’ that would recognize well known devices.
Examples from my own world …
3 switch keyboard pedal switches, Behringer, Motor 61 Kbd, Akai MPK mini, DUOPIANO, Encoder panels, Arduino Pedal board, etc etc,

It’s obviously a big class based set, but perhaps it breaks down by type of message sent and the modifications that can be applied to it.

Some considerations:

  • Would the split be based on the input MIDI channel or the input MIDI device?
  • How many split points should be permitted (unlimited seems reasonable).
  • How would we define which output channel each zone feeds? This really should be freely configurable but that adds to the UI complexity.
  • What happens if we try to define an overlapping split point / zone? It may be advantageous to allow this.
  • Do we want different behaviour for single channel / multi-timbral modes?
  • How does this fit with MIDI routing (current / future)?
  • Do we implement this with filters, e.g. add a simple interface to add / remove splits within the current filter system?
  • Splits should be saved with snapshots
  • We must avoid introducing significant increase in latency
  • There should be a simple way to clear / remove split points / zones
  • I wonder whether this could still be implemented with MIDI routing + MIDI-FX + plugin - even if we need to modify a plugin to add extra zones
  • It would certainly be advantageous to see the split points / zones on an onscreen keyboard. This could be indicated with colour / shading and / or bar above the keys with the MIDI channel shown for each zone. Depending on whether we allow overlapping zones this may need to be wider than a single bar / number. We may need to allow scrolling if the full (127) keys cannot be displayed on one screen.
  • It would be nice to be able to indicate zones by setting colour of lamps on keyboards that support this feature (am I going too far? :wink:) This is starting to sound like zynpad - maybe there is some cross-over / commonality!

I would suggest device. It’s a concept much more wedded to the Source Device

Agreed, It would make for a handy multi sample player or effects machine.

It almost starts at a file format that describes a base grammar of functionality, one well warn paths are described they become default.
Once the file format is established then Webconf config would be based on what we learn. Ideally we want a Behringer 61 to be connected and the flying faders ( or colour lamps … :slight_smile: ) just set themselves up for a Aelios Organ… in a well defined way…
1 Channel 3 25,
2 Channel 5 27
] sort of thing, with definitions for sliders, switches and such as well as Drawbars.

The Ensoniq EPS Sampler made use of this concept to allow layered samples to be used.

It’s really input processing of MIDI so as long as it’s done far enough back up the chain then the zynth shouldn’t care

Long term should MIDI Routing perhaps should be an lv2 component but it’s pretty much the control core of the zynthian. As long as all this processing is done right at the input then it shouldn’t affect too much (yeah right…)


What no python…?
The ability to fire off start up and shut down code via something dumb & stupid. would allow some pre and post config . .

Yes the more general the vision the more difficult to configure a specific type of functionality. Transpose would seem like a standard unit and do we manage the selection/deselection of splits in band or with ANOTHER chunk of generic MIDI filtering…> ( 4 push buttons on Zynth could then turn on and off splits for instance …

It;s a whole response system on the MIDI output side to generate status data. . . A distant zynth should be able to echo the display it that’s what’s wanted … .

There you go top down versus bottom up . :slight_smile:

And the lines on the map, moved from side to side.


maybe something a bit more simple for now could already work as well, some half-baked ideas:

Analogy with Transpose:
Bold click on Layer
Select ‘midi key split’
Present a list with midi channels with radio boxes. This already determines how many splits and the target midi channels. The current midi channel is preselected but can be deselected. (if this ends up not to be too confusing)

On a next screen we show the current splitpoints starting with a default symmetric n-split over a default number of octaves.

Encoders could modify the locations of the split based on octave ranges/asymetry to distribute the split points over and other high level parameters to easily and quickly skew to splitpoints to something sensible and keyboard-friendly.

(optional, expert) listen to the keyboard presses to select the split points. Show which split point you’re editing, maybe use encoder to move cursor

Generate the corresponding lines to Add to the midi filter configuration as seen in webconf. (decorate with comments if this config allows it to show where the entries came from).

A graphic display of the keyboard would be best for feedback, but may not be needed immediately.

Save the config in snapshot so it can be loaded and re-applied.

Iterate starting from something simple but useable.

(Just some random ideas to get some discussion going, intentionally vague…)

Absolutely. It’s cheap to kick ideas around at this stage…

Basic MIDI tools

All Notes Full Velocity
Octave Shift