An area I’ve always never found the time to investigate.
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?
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)
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.
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
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
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.
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) Organnery/aeolus: fork of aeolus engine with additions made for organnery - Audiotronic-git , but I think it is better for Zythian to stick with the official version. Until aeolus v2 comes out hopefully.