Some days ago, John Dey wrote:
> My proposal is to use channel number and 99 to set stops and that > 98 can be reserved for presets. Thus, it wouldn't be necessary to > send the pair--only the MSB or the LSB. Furthermore, NDIVIS > (set to 8) would be reserved for mapping channel to divisions > (many-to-one mapping). The remaining numbers in the MSB, 7 bit > value, can be used for stop assignments.
While using the non-assigned controller numbers is certainly something to be considered, there there are several fundamental problems with the other parts of this proposal.
We don't need anything special for presets - there are standard midi messages for these and they are used in the current code.
2. The midi matrix
There is one thing that should _never_ be controlled via midi, and that is the midi matrix itself ! It serves exactly the _opposite_ purpose : to let the user control how midi messages are interpreted. In other words, midi is the thing _being_ controlled here.
Also, using (channel, value) to modify the routing of note on/off would require Aeolus to listen to control messages on all channels all the time. This goes against the way midi is meant to be used. There could be some channels in a midi stream that have nothing to do with Aeolus and that e.g. control other instruments. This is one of the reasons why the midi matrix exists in the first place.
Also, the midi matrix is not part of the instrument, but it defines the midi interface _to_ the instrument. For note on/off messages it does _not_ map channels to divisions but to virtual keyboards. Notes - the items carried by note on/off messages - are played on a keyboard, not on a division. Keyboard to division mapping _is_ part of the instrument and is done by the couplers. The same is true of the audio controls : they are not part of the organ but define how it relates to the audio world.
3. Stop control
As should already be clear from the previous paragraph, there is within Aeolus a very strict separation between the internal structure and the external interface. It has been a fundamental design decision that the external interfaces of Aeolus should be those of a real organ (with all the limits imposed by organ technology and tradition), and not those of a software synthesiser that happens to make organ-like sounds.
The interface elements of a real organ are
A. keyboards, B. stop, effect and coupler buttons, C. effect controls (tremulant, swell). D. preset controls (on some instruments)
The purpose of the GUI and the midi interface is to control the organ, not the underlying 'engine', so the midi interface should be only in terms of the elements defined above. So for B (the missing part) it should refer to the groups and buttons as they are defined in the instrument definition file and as shown in the GUI.
As said before, midi channels are routed to a keyboard and not to a division. So you can't use the channel number to refer to a division, or a group. Also the midi interface should be able to be used without depending on the current state. So it should also permit to switch stops buttons _on_ and _off_ and not just toggle them.
Finally, I don't think (and this was mentioned before in a reaction to my proposal), that we can ever arrange all types of stops into a fixed number of 'types'. I know such a system is used in some midi files, but that doesn't imply Aeolus has to be able to read those, or any other particular format. It's always possible to write a translation tool that allows the user to map whatever is specified in these files to what is available in Aeolus. It's an artistic decision and I don't think it should be automated.