An area I’ve always never found the time to investigate.
5 Likes
Wow! I love this (hidden) feature. I may never have found it and may never use it but am so happy to know it exists and listen to / watch the video.
Zynthian engine implementation doesn’t parse the instrument file. Instead it hardcodes the default instrument. I remember reading the default instrument file to write the controller list by hand.
Parsing the instrument file to generate the “stops” controller map would be great!
@wyleu, can you feel the force? 
1 Like
hey, I can help you decipher the instrument file if needed, but there a still some things I’ve not totally understood. But the basics to parse the file and get the stops list is totally fine. Let me know if you want some hints
(i’m the skinheaded talker in this video)
2 Likes
Good to know you have a good understanding of Aeolus Instrument Definition files.
What i really want is the parser integrated in the aeolus engine 
The parser output shuld be a Python dictionary with the controllers map, using the same formato that is hardcoded in the engine’s code:
As you can see, it doesn’t seem too complex, but devil live in the little details, you know 
For instance: Presets depends on a given instrument definition. If you have several instrument definitions, you need to have several sets of presets. If you modify an instrument definition file, what does happen with stored presets? etc.
Regards,
1 Like
yes the details are here, especially the preset file, which is a binary file, and for example the midi channels are defined in the presets file.
I make no promise in terms on planning, but I’ll take a look at it to see how it can be done reliably.
You can also have a look at a tool I started to modify the ae0 files, and it is python : Organnery/ae0edit: command line editor for aeolus .ae0 files manipulation of data without usign aeolus gui editor - Audiotronic-git
after a quick look around the aeolus_engine file, I confirm the taskto build the “instrument” dictonary need to read 3 files. First the instrument definition to get the whole structure, then the presets file to get the midi channels (and eventually the saved presets themselves), and also the ae0 files to get the stops names.
presets and ae0 files are binary, you have done part of the job in read_presets_file, and my previously mentioned part for the ae0 file should help in getting the whole thing done.
In order to make sure that aeolus preset files are tied to their respective instrument definition, you have to make sure it is in the same directory, and that you are using ‘-I’ option on startup, and never use the ‘-u’.
If you are to modify an instrument definition file, you own the responsibility to delete the presets file before startup so that it is generated on first save (after a warning has been thrown by aeolus on startup because the fle does not exists). I think it is not a problem as for now there is no existing gui to do this. It is more a developer side of things.
another important fact about :
config_fpath = “/usr/share/aeolus/stops/Aeolus/definition”
If using only the default instruments from the official aeolus debian package (apt install stops), you have 3 instruments definitions installed.
These are the 3 folders Aeolus, Aeolus1, Aeolus2 in the /usr/share/aeolus/stops/ folder.
So either we can make the definition static as part of the standard package, or it would be necessary to start with scanning the stops folder for subfolder containing instrument definition files.
Now if a user wants to add its own instrument definition (through the webui maybe), then you’ll need to save them in another folder and scan it completely to build the correct engine map.
on more … I notice you are using aeolus text mode (’-t’ on startup).
So if zynthian can send commands and parse the output, you could also use the commands instead of midi messages, here are some examples on how to do it (it is undocumented, infos gathered from the code)
Aeolus> S P ?
Stops in group P
- subb16 - prin16 - prin8 - prin4 - oct2
- oct1 - qu513 - qu223 - mixt - bass18
- trom16 - bomb32 - trum8 - CP+1 - CP+2
- CP+3
Aeolus> S P ??
Stops in group P
- subb16 Subbass 16
- prin16 Principal 16
- prin8 Principal 8
- prin4 Principal 4
- oct2 Octave 2
- oct1 Octave 1
- qu513 Quint 5 1/3
- qu223 Quint 2 2/3
- mixt Mixtur
- bass18 Fagott 16
- trom16 Trombone 16
- bomb32 Bombarde 32
- trum8 Trumpet
- CP+1 P+I
- CP+2 P+II
- CP+3 P+III
Aeolus> S P + oct1
Aeolus> S P ?
Stops in group P
- subb16 - prin16 - prin8 - prin4 - oct2
+ oct1 - qu513 - qu223 - mixt - bass18
- trom16 - bomb32 - trum8 - CP+1 - CP+2
- CP+3
Available commands :
commands are 1 character, and separated with one space
‘s’ or ‘S’ : stops enable/disable
second character : group name or
third character :
? : list stops with short names
?? : list stops with long names
+ : enable a stop
fourth character : short stop name to enable
- : disable a stop
fourth character : short stop name to disable
= : disable all stops in the group
‘q’ or ‘Q’ : quit
‘!’ : save
Examples
S P + oct1 >> activate stop oct1 on group P
S P - oct1 >> desactivate stop oct1 on gorup P
S P = >> desactivate all stops on group P
1 Like
We are just changing the way data flows through Zynthian to allow feedback of engine state to the UI. We will update the IPC with Aeolus to monitor it’s state, e.g. stops. Really useful stuff here, thanks.
1 Like
I would find it really useful if there was a way to control the Aeolus reverb from the Zynthian screen. Depending on what I’m playing the preset reverb can be too much.
Even through the Aeolus UI its not easy to adjust. I have to open the Audio Settings window, then each manual has a separate Reverb control. Having those 4 Reverb controls mapped to a single knob would be great.
I have a fork of aeolus where more controls are available through midi (including reverb) https://git.audiotronic.fr/organnery/aeolus , but I think it is better for Zythian to stick with the official version. Until aeolus v2 comes out hopefully.
1 Like
Hi @jerash. The link to your repo is broken. I haven’t found a way to adjust the reverb. Can you help?
[Edit] Don’t worry. I found it at GitHub - Organnery/aeolus-organnery: aeolus pipe organ software clone for Organnery distribution and saw how you are handling parameters such as Reverb. I will add this to Zynthian. Cheers!
1 Like
Hi @riban yes I’ve finally made the transfer to the new github repos as I switched down the dedicated server payed by my company closed last year.
there’s a few things left to move.
If you need help to prepare some dedicated smaller organs (single or double manuals) please let me know, I’m now familiar enough with aeolus config files to build something coherent even if I’m not an proper organist with all the pipe knowledge.
I have some configs ready made with real organists but they are mostly bigger ones.
cheers
1 Like
oh by the way there is a new “fork” based on aeolus engine, built on top of JUCE to generate a vst/au plugin : GitHub - Archie3d/aeolus_plugin: Pipe organ synthesizer (VST plugin)
I’m not familiar enough with JUCE to know if it could help generated a linux native plugin, anyway his implementation is full of CC controls and inventive approach for mixtures, json config files … things that may eventually help with integration in zynthian.
I am looking at the plugin now. JUCE supports LV2 so it might be useful to us. I also spent some time today getting the organny version to build (some odd configs in Makefile were stopping it compililng) but I think there may be too many tweaks for it to be worth us moving to that version. It proved rather challenging to get it to work in a way that would be suitable. There is quite a bit of code that is duplicated for various MIDI and audio layers, e.g. alsa, jack, etc. This adds to confusion and development / support effort. I will see how I get on with the plugin and how performant it is compared to the older standalone version.
[Edit] The standalone version of the JUCE version consumes a lot of CPU (most of three cores) which is much higher than the old version. It looks pretty (which might be what is taking some of that juice). I did compile the LV2 but haven’t managed to persuade it to work but suspect it will be similarly heavy. I will go back to the old version.