Place tremmed samples in separate ranks does not set Pipe999IsTremulant

[oleg68]

When I enable HW to GO - place tremmed samples in separate ranks OdfEdit creates two sets of ranks: one with non-tremmed and one with tremmed samples. But for GO to work with tremulant correctly, OdfEdit has to put Pipe999IsTremulant=0 for all pipes in non-tremmed ranks and Pipe999IsTremulant=1 for all pipes in tremmed ranks.

But now OdfEdit does not put Pipe999IsTremulant at all.

Also all tremmed ranks are not used in stops now. Bot for operating correctly all stops have to reference to both tremmed and non-tremmed ranks.

[eturpault]

I believed that Pipe999IsTremulant was intended only to select pipes/attacks/releases inside the same rank based on wav Tremulant state. If an entire rank can have the same tremulant status for all its pipes it is indeed better to use this attribute as you are suggesting, and thus to avoid as I did in OdfEdit to have an additional stop to control the tremmed rank and an inverting switch to selected between the non-tremmed and tremmed stops. For this use case, could you add an attribute IsTremulant at rank level, similarly to Percussive and HasIndependentRelease ? So we avoid to have one Pipe999IsTremulant attribute for each pipe.

[larspalo]

For this use case, could you add an attribute IsTremulant at rank level, similarly to Percussive and HasIndependentRelease ? So we avoid to have one Pipe999IsTremulant attribute for each pipe.

As I've already said many times now, I'm strongly opposed to that idea and will not approve of it! It's a bad idea from the organ model structural view. I don't care at all about what HW odfs do, or don't do in that regard.

[eturpault]

My suggestion has nothing to see with what HW ODF does, it is intended to lighten the way to describe in GO ODF the fact that all pipes of one rank have the same property, avoiding to repeat the same attribute as many times as there are pipes. It is not a problem for OdfEdit to set one Pipe999IsTremulant value in front of each pipe if you are so strongly opposed to this syntax simplification proposal.

[oleg68]

@eturpault Yes, Pipe999IsTremulant is the only option for making vawe-rank-tremulants to work in GrandOrgue. IsTremulant won't be introduced at the rank level due the opposition by Lars. See https://github.com/GrandOrgue/grandorgue/discussions/878

[eturpault]

Could you please confirm my understanding about how the tremulants (synthetized or wave based) are applied on the pipes. Let's suppose we have a WindchestGroup to which are attached two tremulants : T1 a synthetized tremulant and T2 a wav based tremulant. To this WindchestGroup is attached a Rank as well.

1. If T1 and T2 are both not engaged : the pipes of the Rank which have Pipe999IsTremulant undefined or Pipe999IsTremulant=0 can be played as they are
2. If T1 is engaged and T2 is not engaged : the pipes of the Rank which have Pipe999IsTremulant undefined or Pipe999IsTremulant=0 can be played and are affected by the T1 tremulant
3. If T1 is not engaged and T2 is engaged : the pipes of the Rank which have Pipe999IsTremulant=1 can be played
4. If T1 and T2 are both engaged :
   • the pipes of the Rank which have Pipe999IsTremulant undefined can be played and are affected by the T1 tremulant
   • and the pipes of the Rank which have Pipe999IsTremulant=1 can be played and are affected by the T1 tremulant

Is something wrong in these statements ?

[oleg68]

Let's suppose we have a WindchestGroup to which are attached two tremulants : T1 a synthetized tremulant and T2 a wav based tremulant. To this WindchestGroup is attached a Rank as well.

It is a very strange combination. Usually a windchest has either synthetized or vawe-based tremulants, but not both.

[eturpault]

Several sample sets of Sonus Paradisi give to the user the possibility in a settings panel to choose between synthetized or wav based tremulants. With OdfEdit I convert this possibility by having the two tremulants attached to a same WindchestGroup, and by switches these two tremulants can be activated separately or together depending on how it is defined in the HW ODF.

[eturpault]

I made tests and GO tremulants seems to behave as per my understanding above. I implemented the usage of IsTremulant as you suggested in separate ranks under the same stop when "HW to GO - place tremmed samples in separate ranks" is enabled, it works well and it reduces the number of stops/switches, this is good.

[larspalo]

@eturpault Almost correct. The point 4 above contain a typo, I guess as the last part:

and the pipes of the Rank which have Pipe999IsTremulant=1 can be played and are affected by the T1 tremulant

should be affected by the T2 tremulant.

However, the terminology should really not be "undefined" for Pipe999IsTremulant, Pipe999Attack999IsTremulant, (or their corresponding releases) it's simply defaulting to a value of -1 which means "not affected by a wave-based tremulant" and is thus well defined. That value should be (is) used for any (attacks/releases) that don't have any wave tremulant samples.

When a stop/rank contain wave based samples the attacks/releases should either have the IsTremulant=0 or IsTremulant=1 (for relevent Pipe999 and Pipe999Attack999). The IsTremulant=0 samples can also be affected by a synth tremulant, if it is active, on the same windchestgroup. Most of the time you wouldn't expose the two tremulants to the user - only give a choice of having wave or synth tremulant active by means of a switch and then another single tremulant switch for on/off. For stops/ranks without wave tremulant samples the synth version would always be used while for the wave based a choice will then be available. The IsTremulantDemoSelection.organ in the linked sample set below show this selection possibility and exactly how it works.

Note that the Combo stop/rank in the tremulant demo IsTremulantDemo.organ I link below should of course not at all be used, it's just for demonstration of what happens if both would exist within the same stop/rank!

@oleg68 While testing this, I discovered a bug in GO. It has likely crept in during the re-work of the crossfades. Currently due to this bug, a wave based tremulant will affect a default sample that should not be affected by the wave-based tremulant by triggering a new attacking/fading. Both odfs in the tremulant demo sample set below shows this. For instance in the IsTremulantDemo.organ you can activate the Plain stop, hold down a key and activate/de-activate the Wave tremulant (that should not affect the Plain stop at all that have a default value of IsTremulant=-1) and hear the effect of the bug.

TremulantDemo.zip

This sample set assumes GO v3.14.0, an earlier version needs the Percussive=N value added to the ranks.

[eturpault]

Indeed I made a typo, thanks for the correction. By IsTremulant "undefined" I implied that it is set at -1 by default as you said. It is good that you confirm that the IsTremulant=0 samples can be affected by a synth tremulant if it is active, so what I implemented in OdfEdit can work. The Combo stop/rank of your example is not something that OdfEdit can generate, it is generates either Plain, or Wave, or Wave split in two ranks (one with IsTremulant=0 for all the samples and one with IsTremulant=1 for all the samples if requested by the user in the menu).

About the Sonus Paradisi sample sets which offer the possibility to select between natural (wave based) and artificial (synthetized) tremulants, strangely when the wave based tremulant is used, the synthetized tremulant is activated as well by the same switch, this is not good but it is defined like this in the HW ODF. It is the case of Buckeburg sample set for example. It means that when both wave based and synthetized tremulants are activated, samples with IsTremulant=0 and IsTremulant=1 can be played by GO.

[larspalo]

It means that when both wave based and synthetized tremulants are activated, samples with IsTremulant=0 and IsTremulant=1 can be played by GO.

Not sure what you mean with this sentence. If a sample has IsTremulant=0 it won't be played when the wave tremulant is active, and thus cannot be affected by the synth tremulant at that time. However, if the wave tremulant is in-active the IsTremulant=0 sample is played and can be affected by the synth tremulant.

In the IsTremulantDemoSelection.organ above you can clearly see both the backend tremulants be activated by the front-end Tremulant if the switch "Use Wave Tremulant Samples" is active. At that time, the Plain samples are affected by the Synth tremulant and the IsTremulant=1 samples are affected by the Wave tremulant and the IsTremulant=0 sample are not played at all.

[eturpault]

Ok my understanding was not correct when the two tremulants are active, it is nice that IsTremulant=0 samples are not played at all.

[oleg68]

@oleg68 While testing this, I discovered a bug in GO. It has likely crept in during the re-work of the crossfades. Currently due to this bug, a wave based tremulant will affect a default sample that should not be affected by the wave-based tremulant by triggering a new attacking/fading. Both odfs in the tremulant demo sample set below shows this. For instance in the IsTremulantDemo.organ you can activate the Plain stop, hold down a key and activate/de-activate the Wave tremulant (that should not affect the Plain stop at all that have a default value of IsTremulant=-1) and hear the effect of the bug.

TremulantDemo.zip

This sample set assumes GO v3.14.0, an earlier version needs the Percussive=N value added to the ranks.

@larspalo please open an issue with this bug. Otherwise I may forget about it.

[eturpault]

This is fixed in OdfEdit v2.11