There are a few things to consider when planning any scheme for external stop control. The MIDI messages as defined in the README support both those systems that maintain their own state and use 'set on' and 'set off' messages, and those that don't have any internal state and only use 'toggle' commands. This is intentional - I wanted a protocol that would permit all possible forms of external control.
The latter are the easiest to deal with. In this case, your stop switches do not show if a stop is 'on' or 'off', they are just pushbuttons that toggle the state of a stop. You need to see the Aeolus GUI to know if a stop is 'on' or 'off'. This also means you can still modify stops in the GUI, and you can still use the presets system built into Aeolus.
In case you would use stop switches that _do_ show the state of a stop, i.e. that have a visually distinct 'on' and 'off' state, you should not use the GUI nor the presets - the real state could be different from what your switches are showing. So in that case, if you want presets, they must be implemented by your external control system. There is currently no output from Aeolus that you could use to change the state of your stop buttons, either mechanically or e.g. by a light built into them.
Anyway, the protocol you use should either be the built-in one, or if it's different, you will need an external program to translate your commands to the form that Aeolus understands. There is *no way* I will ever build any other particular command set into Aeolus - there would be no end to all the possible variations I would need to support.
Translating MIDI commands and patching a such a translator in between your console and Aeolus is easy enough. If you have a particular stop control system in mind, I'd be happy to write the translator. But first you should be well aware of the consequences of your choice, and how you want to use it.