Feature request : reversible General piston

[eturpault]

In order to have a chance to convert the combination buttons of the Szczecinek sample set from Hauptwerk to GrandOrgue ODF by OdfEdit (discussed here GrandOrgue/OdfEdit#50), I would need that a General push button (old style General section) had the possibility to be disengaged when one press on it whereas it is engaged, and that at the same time that all switches (and drawstops) which are referenced in this General are disengaged as well. So it would be a General with a reversible piston behavior.
This would permit to give the control to the standard stops when the free/fixed combinations and "Registratur absteller" button are all disengaged (like it is defined in the HW ODF).
It could be a default behavior of the General, or it could be set by a new boolean attribute called for example IsReversible.
It could be applied to Division as well.
Would it be possible to add this feature ?
Thank you.

[larspalo]

Would it be possible to add this feature ?

More or less everything is possible, but that doesn't mean that it "should" be done like that (no matter what might be done in some HW odf).

It could be a default behavior of the General

I don't think this is the right way to go about it as this is most definitely not the default behaviour of generals/divisionals as far as I know. Nor am I so convinced that we should necessarily add more odf options for the odf generals/divisionals in themselves to alter their behaviour.

Generals/divisionals are usually expected to visibly affect the drawstop states "one way" when they are pushed. For that type of combination system that were discussed and mentioned above, it's really not at all desired that the state of any drawstop should change (only what set of activators get precedence at the moment) - nothing beyond the "selector" state itself should change. Also, it seems that quite a few "Auslöser" functionality is not mentioned in that particular organ even though it's very common and integral for that pneumatic type combination system (nor is it mentioned on the website information about the organ, even if it's kind of visible in the images that they exist).

Most of the pneumatic "fixed combinations" or even the type of "full organ" reversibles that I'm aware of should never visibly affect any drawstop state either, it's just the "reversible piston" itself that has it's state changed to indicate that it's in effect. Perhaps it's instead the reversible piston type of GrandOrgue that should be altered in order to be more versatile and capable?

[oleg68]

@eturpault Have you tried to use negative stop and switch numbers in the GeneralXXX section?

[eturpault]

The combinations buttons of this sample set (Registratur absteller, Freie 1, Freie 2, Piano, Mezzoforte, Forte, Tutti) are defined as latching switches in the HW ODF, with the following behaviors :

• when one switch is engaged, it disengages the 6 other switches (mutual exclusion between them). This is done through 6 switch linkage sections which are configured to disengage their destination switch when their source switch is engaged. These switch linkage sections have no effect on their destination switch when their source switch is disengaged.
• while one of these switches is engaged, the standard drawstops are not applied.

In GO ODF, only General sections can do the job to manage the mutual exclusion and to control switches states.
In order to have all these 7 switches disengaged (to permit the application of the standard drawstops), I need what I described in my first comment.
Negative stops will not help I think in this use case.

Maybe a ReversiblePiston sections would permit to fulfill this need (mutual exclusions and possibility to disengage the controlled switches without having to press another piston), but the help of GrandOrgue does not describe to use it.
Which are the attributes of a ReversiblePiston section in the current version of GrandOrgue ?

[oleg68]

Negative switches in the general section are what you want. Could you try this and tell what doesn't work as expected.

[larspalo]

@eturpault Sorry, could you please describe exactly what's done in the HW odf that cannot be done in GO (and not only guesses - but actual HW behaviour)? As I've already mentioned, for that specific type of combination system in question, I have already helped Mark to do a working example with Ta'Xbiex. But that's basically beyond the scope of OdfEdit if it's not actually already working in the HW odf. In other words, what's really interesting is to know exactly what's done in HW and how to possibly be able to transfer that to the GO odf. As I'm hinting at, I'm not even sure that the author of that sample set in question has done the "right" thing in modelling that organ in HW (there's no way for me to test it) - but what's interesting for you, asking for a feature, might be to show us what can be done in the HW odf that cannot (currently) be done in GO? You mention "latching switches" but what exactly is done that cannot already be achieved in GO? What kind of logical function is currently missing from the GO switches?

Which are the attributes of a ReversiblePiston section in the current version of GrandOrgue ?

The reversible pistons can currently only be an additional way to access/trigger any single type of drawstop (Stop, Coupler, Switch or Tremulant) from another element (the reversible piston). In its current state it's very close to being obsolete as there are other ways to (visibly) do exactly the same thing. That's because its existance pre-dates the new panel format and the Switch functionality, going back to a time when no other possibility for such things existed. But, in my opinion, it might be interesting to now expand the reversible piston functionality from the very limited use it currently has so that more use cases could exist for it. It might for instance be triggering any other odf divisional or general (reversibly).

[oleg68]

Maybe a ReversiblePiston sections would permit to fulfill this need (mutual exclusions and possibility to disengage the controlled switches without having to press another piston)

Mutual exclusion should be done with Generals

[General001]
Name=Piano
NumberOfStwitches=3 ; all the stops
Switch001=001    ; engager this switch
Switch002=-002   ; disengager this switch
Switch003=-003   ; disengager this switch

and so on

[eturpault]

OdfEdit v2.13 already generates General sections as you have described, for fixed combinations.
Below is the logic behind the combination and stop switches (example with only one stop to simplify the diagram) as it is implemented in the HW ODF.

What cannot be done with GO ODF is to disengage the switch AnyCombSelected (at the bottom of the diagram).
All green switches have to be converted in General sections in order to have their mutual exclusion (but Auslöser which is a non latching switch). Once one general button is pressed, it is not possible to have all the general button disengaged (but by using General Cancel, but this would disengage the normal stops as well), so not possible to have AnyCombSelected disengaged and to have the standard drawstop switches controlling their stop.
I hope it is more clear like that.

[larspalo]

@eturpault To me the un-clear thing above is how the switches are disengaging each other in the HW odf. How that kind of feedback/interaction mechanism works is not described.

Basically what I and Mark did to solve such interaction was to set all the green switches with a minimal mouse rect to not receive any user input and overlay each of them with a transparent general that handles the mutual exclusion but is not in itself "visible" whatever it's "state" might be. The user would believe to be interacting with the visible switches but would in reality interact with the fixed combination general(s).

In your drawing above if the "Switch auslöser" again would be an invisible general that disables all other green switches the "Switch AnyCombSelected" wouldn't get any input at that point and thus be reversed by the NOT to activate the manual drawstops, right?

[larspalo]

@eturpault Now that I've slept a little I think it's perhaps easier in your case to never display the green switches and have the "Auslöser" general with the same on/off image that deactivates the other green switches "without having a state" itself.

I'll see if I have time later today to test such a setup.

[larspalo]

@eturpault Just wanted to chime in and say that the strategy above works just fine to implement in GO in my testing. The switch complexity gets rather overwhelming, but it works. It's hard to say if there are any advantages to this particular implementation over the XOR version I and Mark did with Ta'Xbiex (which I think might use slightly less number of switches), but the main point is that the mutual exclusion mentioned above is perfectly possible to implement with odf generals in such a switch network.

[eturpault]

@larspalo The way the switches are disengaging each other is described in my previous message (#1928 (comment)) using SwitchLinkage sections, which the effects cannot all be converted in GO ODF syntax (for example engage and disengage actions can be defined separately, each can be engager, disengager, none action), I prefered to not describe it in the diagram to not make it too heavy.

Thinking about the diagram that I made, indeed you are right the switch Auslöser (which is currently ignored by OdfEdit because it has a disengaging effect only) should be converted into a General button and thus would permit to disengage all other General buttons, and as it is not an input of the AnyCombSelected switch it allows to activate the manual drawstops.
The only (little) problem is that in the sample set the switch Auslöser is displayed only in the Console panel, not in the Stops panel.
I have to find how to convert this switches network automatically with OdfEdit (which can only do conversion, it cannot invent another logic).

[larspalo]

I have to find how to convert this switches network automatically with OdfEdit (which can only do conversion, it cannot invent another logic).

You're absolutely right (correct) with that approach! Also, remember that this particular organ type combination system is quite a "corner case" that is fairly un-usual and mostly obsolete by todays standards. Nevertheless, it's nice to be able to model it. Thanks for your efforts!

[oleg68]

@eturpault This is my approach of implementing your diagram with current GO version:

[Switch001]
Name="I Principal 16'"

[Switch002]
Name="Freie Combination 1 I Principal 16'"

[Switch003]
Name="Freie Combination 2 I Principal 16'"

[Switch004]
Name="Any Fixed Combination I Principal 16'"

[Switch005]
Name="Any Combination Selected'"

[Switch006]
Name="Freie Combination 1 Selected'"

[Switch007]
Name="Freie Combination 1 Selected'"

[General001]
Name="Freie Combination 1"
Switch001=005 ; AnyCombination Selected
Switch002=006 ; Freie 1
Switch003=-007 ; No Freie 2
Switch004=-004 ; Disengage Principal16 for fixed combinations

[General002]
Name="Freie Combination 2"
Switch001=005 ; AnyCombination Selected
Switch002=-006 ; No Freie 1
Switch003=007 ; Freie 2
Switch004=-004 ; Disengage Principal16 for fixed combinations

[General003]
Name="Ausloser"
Switch001=-005 ; No AnyCombination Selected
Switch002=-006 ; No Freie 1
Switch003=-007 ; No Freie 2
Switch004=-004 ; Disengage Principal16 for fixed combinations
IsPushButton=Y

[General004]
Name="Piano"
Switch001=005 ; AnyCombination Selected
Switch002=-006 ; No Freie 1
Switch003=-007 ; No Freie 2
Switch004=-004 ; If Principal16 is disengaged in "Piano"
; Switch004=004 ; If Principal16 is engaged in "Piano"

[General005]
Name="Mezzoforte"
Switch001=005 ; AnyCombination Selected
Switch002=-006 ; No Freie 1
Switch003=-007 ; No Freie 2
Switch004=-004 ; If Principal16 is disengaged in "Mezzoforte"
; Switch004=004 ; If Principal16 is engaged in "Mezzoforte"

[General006] ; The same approach for other fixed combinations

[eturpault]

Thanks @oleg68. This approach is indeed what I must aim for.
Here you are controlling the AnyCombSelected switch directly inside the generals, this is a simplification compared to what is defined in the HW ODF where each general has its own status switch and AnyCombSelected is an OR of the status switches. I cannot do this simplification in an automatic way from the HW ODF.
Disengaging the Switch004 in the Freie Comb. 1/2 generals is not necessary I think, as the Principal 16' stop status is set by the Freie 1/2 drawstops.
Just one typo : Switch007's name is "Freie Combination 2 Selected".

[oleg68]

Thanks @oleg68. Here you are controlling the AnyCombSelected switch directly inside the generals, this is a simplification compared to what is defined in the HW ODF where each general has its own status switch and AnyCombSelected is an OR of the status switches.

Your variant is also workable.

Disengaging the Switch004 in the Freie Comb. 1/2 generals is not necessary I think, as the Principal 16' stop status is set by the Freie 1/2 drawstops.

If any fixed cmb was pressed where P16 presents and then you press a free cmb without P16, you need P16 would disengaged.

According to your diagram, P16 can come from a (disengaged) fixed cmb to the OR.

Another possible solution is to have a switch "Any FIXED cmb selected" with AND relation to P16fixed.

But the easiest solution (including for automatic built) is to have the same element list in all generals but with different statuses: -1 - disengage, 1 - engage, 0 - keep unchanged

[larspalo]

@oleg68 Your example is incomplete as it doesn't show the backend stop function and omit the linkage/selection between the different active trigger switches nor which are displayed and which wouldn't be. Also, I believe that the:

IsPushButton=Y

most likely should be DisplayAsPiston instead.

The scheme that @eturpault presented is working nicely with just a fairly small edit already mentioned above - so, I present a fully functional demo example sample set below which is of course only as good an implementation of the scheme as I understand it (one of the doubts I had was about how the "Registratur Absteller" vs the "Rollschweller" and its own accompanying "Auslöser" actually would tie together/work, so I made a composite solution quite close to the solution we used for Ta'Xbiex where the "Auslöser", in this case, always would return control to the main drawstops. The "Registratur Absteller" switches control to the rollschweller and must be programmed as active into each crescendo step so that as soon as the crescendo swell pedal is moved it will go into action - this might of course not be the case in the real organ, I just don't know that)...

PneumaticCombinations.zip

[eturpault]

I am closing this discussion in link with this comment in OdfEdit space : GrandOrgue/OdfEdit#50 (comment)

[oleg68]

Now I'm working on adding an internal OR switch to any drawstop. It will make such ODFs a little bit simpler.

[eturpault]

A drawstop has the attributes SwitchCount, Switch999 and Function permitting to have an input OR switch, what will be this internal OR switch that you are going to add ?

[oleg68]

The idea is to have the additional OR entries in a regular INPUT drawstop.