MIDI Filter Rule Sytem (it was "Disable program change reception?")

I use the Zynthian with the keyboard of a dsi mopho synth. Unfortunately the editing of the global parameters for sending midi parameters or midi messages does not really seem to work, so i cannot disable that the progam changes are beeing sent. which is very annoying because in my live setup I want to use sounds from the zynthian aswell as sounds from the mopho and change between the two by running the zynthian into the audio in of the mopho and selecting the zynthian by switching to a preset where the audio-in is active (which now unfortunately also changes the preset in the zynthian, so I would always have to reset the zynthian sound that i wanted to play).

@jofemodo
We could have checkboxes in the midi section of the webconf for every cc group.

Besides. Does anybody else has an issue with KeyUp after a PitchBend? That it has the pitch of the key and not the bent key? It could be my keyboard…have to test with another one as well before I debug :slight_smile:

like this?

1 Like

While we are at it, we could implement a cc message translation as well:
breath to modulation:
2=1, other translations

Maybe not a filter like in the previous screenshot, but

Translate CC events (1011) (i.e. 2=1,4=OFF)

1 Like

“Filter” is technical jargon. I would use “Ignore” to clearly describe what will happen if you check the box.

What do the 4 digits in parentheses mean?

What exactly is supposed to be entered in the text field labelled “Filter CC events (1011)(comma separated)”? Could you provide a couple of examples?

(I am trying to document all this stuff…)

1 Like

The numbers are for @jofemodo. He knows what to do with it. In the final layout, they are gone.
The 2=1 means, that Breath Control CC 2 messages are translated into CC 1 modulation messages.
All fields are expert fields. In the future we will have a switch to be able to hide them.

1 Like

OK! I like the idea, but we should think of creating the mechanism for hidding the advanced fields. The list getting too long … A little bit of javascript will do the trick quite easily. JQuery library is already included … :wink:

Also, i prefer using “Ignore” better than “filter”. The “translate CC” option is nice too.
All this options would be “global”, applied to all channels. I’m working in the “per-channel translate CC”, but would be presented as a “MIDI learn” feature that will be stored with the “snapshot”.

Regards!

  • Regarding the “ignore” feature, perhaps it could be presented as a “multi-select” widget?
  • Perhpas the “translate” feature could be a “textarea”, and we can define a small script-language for MIDI filtering.

Something like that:

IGNORE PG
IGNORE CH#6:9 KP
IGNORE CH#6 CP
IGNORE PB
IGNORE CC#4
IGNORE CH#5:8 CC#16,17
TRANS CC#5 => CC#18
TRANS CH#4 CC#76 => CC#87

Where event types code are:

  • PG => Program change
  • KP => Polyphonic Key Pressure (Aftertouch)
  • CP => Channel Pressure (Aftertouch)
  • PB => Pitch Bending
  • CC => Continuous Controller Change

Regards,

1 Like

I like the idea of the script-language.
the “multi-select” widget could be a panel of inputs which create those commands.

  1. select Command [IGNORE|TRANS]
  2. MutliSelect Channel [ALL (0), 1-16]
  3. Select MidiEvent [PG…CC]
    If MidiEvent is CC, the following will be displayed as well
  4. MultiSelect CCValue [1…127?]
    If command is TRANS and only one CCValue is selected, the following is displayed:
  5. MultiSelect TranslatedCCValue [1…127?]

Or do you want to be able to translate a CC#76 to a KP or sth else as well?
In this case, we need a TranslatedMidiEvent as well.

1 Like

Yes, “translated MIDI event” too … why not? :wink:

Note: The filter script should be “stored” in a single environment variable (command/line). Do you agree?

We need to talk about the range a little.
Should this be possible as well?
5:8,13,14:16

Do we really want to make it more complicated than necessary?
Or are we happy with the comma separated notation? In the end there are only 16 values…15…16 would be 0 :slight_smile:

I’m happy because we have the first practical application for the MIDI-OUT connector. Zynthian could be used as a standalone MIDI filter device …nice!!! :sunglasses:

Regards!

It’s not so complex … i will code the “parser” as a python library, so you don’t need to worry about it :wink:

Regards!

I have to fill the textarea… It’s an additional step for me to optimize a list to this shorter form…or i don’t.

The challenge for me will be to code this in pure javascript, because I don’t want to break the config-block.html structure.
BTW.

so great you guys are already working on this!
would be also nice to have the mod wheel separately de/selectable

@jofemodo, the github branch is githubNo19

1 Like

Hi @zynthianters!

I’ve extended the MIDI filter core functionality. Now it’s possible to map almost any event in any channel to any event in the same or different channel. Note-on/off events are not supported supported right now, but it could be done quite easily if you think it’s interesting.

In order to easily configure the filter, a simple rule system has been implemented. You can take a look to the parse here:

This functionality will be available from the webconf tool. @mheidt is finishing the integration :wink:

Enjoy!

2 Likes

thanks fernando!
It’s not yet doable without the webconf integration did i get that right?
Looking forward to it, this will be so useful for me!

Hi @Zynthianers!

Finally we have the new “MIDI Filter Rule System” feature integrated in the webconf tool. You can create your rules by hand or using the wonderful “rule composition” dialog.

As you probably remember, we have developed a simple “MIDI Filter Rule Language” that can be used for creating rule sets (scripts) that can do a lot of interesting tricks with your MIDI input flow. If you have a MIDI-OUT (like the new Zynthian Kits v2 have), you can use your Zynthian Box as a powerful standalone MIDI filter.

Here is the MIDI Filter Rule Language syntax:

Rule Formats:

  • IGNORE [CH#??] EV[#??]
  • MAP [CH#??] EV[#??] => [CH#??] EV[#??]
  • CLEAN [CH#??] EV[#??]

Event types:

  • PG => Program Change
  • KP => Key Press (after-touch)
  • CP => Channel Press (after-touch)
  • PB => Pitch Bending
  • CC#?? => Continuous Controller Change (??=controller number)

Numeric expressions:

  • 5 => a single number
  • 5,6,7 => a list of numbers
  • 5:7 => a range of numbers, including both limitters
  • 1,2,3:5 => a mix of lists and ranges

Some Examples:

  • IGNORE CH#2 PG => It will ignore Program Change events coming from channel 2
  • MAP CH#1 CC#7 => CC#1 => It will translate Volume Control events from channel 1 to Modulation Wheel events in the same channel
  • MAP CH#1 CC#0:127 => CH#2 CC#0:127 => It will translate all the CC (Continuous Controller) events from channel 1 to channel 2

Thanks to @mheidt who have done the webconf integration and help me a lot testing the parser. I love you man :heart_eyes:

Enjoy!

4 Likes

Cool thank you guys!
Only where do I find the rule composition dialog? I cant see it in nowhere in the webconf? And I dont know how/where to do it by hand.