I’ve now successfully assembled two Zynthians. The first is an official kit v4.4 (awesome build!) and will be for my tinkering/testing/gigging. The second is a more modest build, housed in a SmariPi case with the official 7" touchscreen and no encoders, to be installed as a sound module on my church’s 2-manual Allen organ.
Hopefully soon I’ll have some photos and samples to share!
I love this project and have been reading the forums extensively. It’s scratching a serious itch I’ve had for years to see such a robust open-hardware-and-software project showing consistent growth and improvement.
I do have a question that I haven’t been able to determine from the existing forum discussions. The two most organ-console friendly engines (Aeolus and setBfree) both load with automatic channel mapping that doesn’t align with how the Allen organ transmits MIDI data. I’m on an AP-4 model ('98 era) that maps like this:
- Swell → Channel 1
- Great → Channel 2
- Pedal → Channel 3
When using Aeolus, I’ve been able to modify the midi mapping in the native GUI which works, though the Zynthian UI still shows Pedal on channel 1, etc. Should the channel mapping adjust in the main UI as well, or is that basically a limitation of the implementation?
When using setBfree (upper + lower + pedals on 3 MIDI channels) the layers are automatically mapped and I can’t figure out how to change the channel mapping. I’ve tinkered with the setBfree native GUI on a different machine and didn’t find anything. What I want to achieve is this:
- Upper → Channel 1
- Lower → Channel 2
- Pedal → Channel 3
Thanks for the help!
1 Like
Hi @plimptm !
Regarding Aeolus, zynthian uses a fixed configuration on channels 1-4 that you shouldn’t try to modify from the Aolus GUI.
Manual III => CH#1
Manual II => CH#2
Manual I => CH#3
Pedals => CH#4
Also, you shouldn’t use a different instrument definition from the default one, as this default configuration is also “hardcoded” on the UI. For loading different “instrument definitions”, we should implement a parser that read these files and generates the UI configuration “on-the flight”. If you think this is interesting, please feel free to open a feature on our issue tracker.
Regarding setBfree, it should take n consecutive channels from the chosen one. If some of this channels is being used, it would look forward up to the next free channel.
For achieving what you want, you simply remove all layers and create a new setBfree layer, choosing “channel 1”.
Of course, don’t forget to enable multi-timbral mode (disable stage mode) from the admin menu 
Cheers!
Thank you, this is very helpful!
I tested the setBfree again and it did map channels 1,2,3 to the corresponding keyboards automatically. I’m not sure why it didn’t work the first time…
The only thing that needed adjusting was the pedal, which was transmitting note messages an octave higher than expected. But that was easily fixed with the transpose option.
Regarding Aeolus…
I’m definitely interested in opening a feature request for the custom instrument definition idea you described. The organ I’m using is also fixed in what channels each keyboard transmit, and if anyone else is interested in doing what I’m doing with an older organ that would be quite useful.
For reference, here’s what I’ve found:
- I got the idea to modify the channel mapping in the native UI from this wiki page
- Roughly speaking, it works. That is, once modifying the channel mapping in the native UI and hitting the Save button there, my Pedals play the pedal division, Great manual plays I and swell plays II, as desired.
- However, the channel numbers are still listed in the Zynthian UI as originally loaded
- When adding a new synth layer to one of my manuals, I have to clone the MIDI from the ACTUAL channel number being played rather than the rank of stops that I’m attempting to layer on top of. (E.g. my pedals transmit on Channel 3, so to add a new bass layer i have to clone MIDI from channel #3, which is labeled manual II rather than the layer labeled pedal). This is not surprising given the changes I made in the native UI, just a bit counter-intuitive and not something I would want to attempt on the fly.
- I was able to populate extra banks/presets using the native UI. The default instrument configuration contains 2 banks each with 2 presets, and I was looking for multiple banks each with 7 presets (my organ has 7 general pistons that send program change messages so this is the ideal layout). I just toggling through the bank and preset selectors and hitting ‘Store’ on each desired preset. Finished with a save, and after restarting the Zynthian UI (or rebooting - can’t remember) the Zynthian UI was now populated with all of the banks and preset numbers.
- modifying/saving registrations in the native UI proved troublesome - I’m guessing this is where there were conflicts between what Aeolus had stored in its configuration files and the configuration of the Zynthian Aeolus engine. I combed through and set all my registrations using the Zynthian UI, assigned the pistons using program change learn, saved a Z3S, and I’ve got a solid set up.
Thanks for the work you’ve put in developing this engine the past few years. I’ve always loved the Aeolus tone and how computationally cheap it is compared to sampled pipe organs. Add to that the ability to switch easily between pipe organ, Hammond B3, and a whole library of synths and samples, this is a big win already.
As I parse these out I’ll get over to the issue tracker in the near future and start working on the feature request. I’d also like to contribute some of my experience with Aeolus to the wiki.
1 Like