e9925248
New member
That's great, but my suggestion goes further than that (besides that it would be a much neater way to solve the problem). It's about creating logic from how a real organ works with its divisions on different windchests and also have another motivation to why different windchests should be modelled in the odf. Think about it, please!
The GO organ modell is more flexible.
Before introducing the multi-rank support, GO used organ->manual->stop->pipe listing in the organ dialog. The manual was a non-functional label to get a little bit of structure in the list.
With the multi-rank support, the stop was replaced with the rank. As there is no association between rank and manual and a plain rank list is not very user friendly, I needed something new. The only possible replacement was the default windchest of the rank.
GO allows to place indiviual pipes of a rank on different windchests - the rank windchest is just the default windchests, if no override is in effect.
Therefore the windchest was introduced as non-functional grouping.
Allowing to specifiy settings on windchest level can lead to strange behaviour: While pipe A inherits its settings from the default windchest, pipe B of the same rank can inherit its settings from a different windchest - but the user can't recognize this.
In my option we can only help the user by eg. translating a click on a windchest into the selections of all its ranks.