After running into a few issues in programming the midi filter rules, I think the following example should be added to the wiki: https://wiki.zynthian.org/index.php/Configure_MIDI_Filter/Router
Map any channel CC59 to Channel 15 CC120:
MAP CH#0:15 CC#59 => CH#15,15,15,15,15,15,15,15,15,15,15,15,15,15,15,15 CC#120
I also mapped in an audio record button
//Audio Record button Start/Stop Toggle
MAP CH#0:15 CC#117 => CH#15,15,15,15,15,15,15,15,15,15,15,15,15,15,15,15 NON#23
So now I finally have a sample of my zynthian!
Chan 1: JV/Fluid Pianos into JV/Tal-Reverb (Upper Keyboard: Novation Launchkey 49)
Chan 3: setBfree w/ x42Whirl (Lower Keyboard: Axiom 61)
You may proceed onto Valhalla as fully fledged!!! 
Nice piece! I keep expecting to hear Elton John come in with the first line of lyric!
I will improve the parser for supporting 1=>N & N=>1 assignment …
Thanks for sharing the trick! I didn’t know it!! 
Jeje,
Thanks for the parser! I love this project.
Yeah, after getting a few mapping failures and looking at the examples I realized repeating the same number over and over would fill out the struct as expected 
After looking at the code, I’d expect that the internal solution will be to expand out the mapping behind the scenes.
Any chance you could implement CH# CC# VAL# => CH# CC# VAL# while you are in that code? I was about to start looking around to see what I could do to add assignment.
OK! Mapping N=>1 is already implemented. I just commited …
Mapping 1=>N is more complex to implement, sorry. Implementing this is not easy with the current paradigm.
Same for this. The current paradigm doesn’t allow to make this easily. Sorry …
Regards,
Thanks @jofemodo,
I did some digging around on my own and yes, there would be significant rework involved in getting this to work with value assignments. Ideally it would also support N=>1 value assignments.
If I can get a VM running zynth, I’d probably clone and start hacking around a bit more. I’m getting tired of messing up my rig. Finally got smart and cloned the SD card as a backup.
Could you confirm that N=>1 mapping is working fine for your use case?
I mean …
MAP CH#0:15 CC#59 => CH#15,15,15,15,15,15,15,15,15,15,15,15,15,15,15,15 CC#120
could be replaced by:
MAP CH#0:15 CC#59 => CH#15 CC#120
Regards,
Yes,Thank you! This works great!
One more request/suggestion.
Any chance that the MIDI filter Rules could be changed to 1:16 rather than 0:15?
The 1:16 values are what are presented everywhere else MIDI is used.
Always a problem this one. Coders are going to prefer 0-15 users probably would prefer 1-16 and some of us change depending on the day and the weather.
Perhaps we could embed logic in the mapping parser?
=> is base 0
==> is base 1
It avoids the almost inevitable webconf midi base option, and would mean that cut and pasted settings would work consistently.
Should we translate the logs as well? I would only go 1-based in the webconf builder tool.
MIDI channel numbers should be presented 1-based (1-16) everywhere to users. zero-based indexing should only be within code. All user interfaces should be 1-16. Let’s make this consistent so that both coders and users don’t have to figure out what is happening at different parts of the interface.
OK! Let’s do it …
BTW, this also should be do it:
Regards,
Could we do it after we have a official buster?
I don’t expect a stable version soon when we touch that
I see that the rule builder already use channels 1-16, so only MIDI logger should be changed, and this is quite easy.
Changing the rule parser itself is my task, and i don’t think it’s a priority, so it could be done after the Buster release.
Regards,
See, what I mean? 
I can change the log easily soon.
Oh boy! Sorry I kicked the hornets nest
I’m a coder, and a musician. In this case I just want it to match the “MIDI Channel” that is displayed on my keyboard controller when I’m writing rules… and this can wait. I’d rather have an official buster!