Feature request: to support silent attack pipe in a rank

[eturpault]

In order to implement stop disengage or key release noise, it is currently necessary with GrandOrgue to define an attack pipe refering to a silent sample. This method is used by Piotr Grabowski and OdfEdit v2.1/2.2. In order to avoid to have to include in the sample set a wav file with no sound inside (so to play a silent attack sample), this request is to add in GO the possibility to name a pipe attack as "SILENT" in a rank so that GO doesn't emit attack sound for this pipe and can emit release sound for the same pipe. The syntax should be : Pipe999=SILENT Pipe999=DUMMY cannot be used in this case since the pipe release sample is dummy as well.

Example of pipe new definition in this case :

Pipe001=SILENT
Pipe001ReleaseCount=1
Pipe001Release001=Noises\Releases\036-c.wav

instead of currently :

Pipe001=Noises\SilentLoop.wav
Pipe001ReleaseCount=1
Pipe001Release001=Noises\Releases\036-c.wav

[oleg68]

Should GO play the release sample in this case?

[eturpault]

Yes correct. This should be a way to have a pipe which the attack is silent (not played) and the played release is the one given in the Pipe999Release999 attribute. With the setting Pipe999=DUMMY I observed that the release sample of this pipe is ignored.

[larspalo]

I think we should implement this in a better way. Looking at the real use case (effect stops like tracker action and stop noises) we should have a kind of hybrid between the Percussive=Y and Percussive=N. I think that another boolean setting could be added to the rank (or pipe) that specify that (if true) it can have both attacks and releases but will play them back without any loops, basically just a percussive pipe with release(s). We could name it "PercussiveRelease", "NoiseEffect", "UseRelease" or whatever. What that would do is enable us to keep both parts of the noise on and noise off in the same rank and avoid having to resort to tricks like multiple ranks, silent loops or looping the last sample of the attack etc. This should of course work both for tracker and stop noises (when only one single pipe is defined for the rank, or if multiple are for the former case).

[eturpault]

Indeed in this use case the need is to play a percussive release sample without attack sample in the stop (the attack sample is managed in another stop). What I observed in the HW sample sets is that for the tracker actions or stop noises, there is one sample file for the attack noise (without loop inside) and another sample file for the release noise (without loop inside), and the link between the attack and release samples is not necessarily provided. So the solution is to have a stop to play the attack sample only (percussive), and another stop to play the release sample only (percussive).

[larspalo]

So the solution is to have a stop to play the attack sample only (percussive), and another stop to play the release sample only (percussive).

And this is exactly what we should not do.

[eturpault]

I agree, the best should be to have a single stop containing both the percussive attack and the percussive release of the noise to render. But with some HW sample set where the attack and release noise are defined separately, it would require more processing to assemble them in a single stop, so I generate two stops. If you make possible to support both percussive attack and percussive release in the same stop, I will see how to use it in OdfEdit.

[larspalo]

I will see how to use it in OdfEdit.

It should be fairly easy to assemble the one complete stop even from different directories if you just know what to look for.

[eturpault]

Yes I agree, it is only a matter of SW programming.

[oleg68]

@eturpault

Why not

Pipe001=Noises\Releases\036-c.wav
Pipe001Percussive=Y
Pipe001ReleaseCount=0

?

[larspalo]

Percussive ranks/stops only activate on note on, what we eventually will need is triggering on note off. Thus, percussive with release. I propose we add another boolean like PercussiveWithRelease to load the release too and keep track of the note on until released. Or would you like that we just modify the percussive to allow releases (and keep track of note on)?

[oleg68]

But noise effects are not related to note on/off.

I propose we add another boolean like PercussiveWithRelease to load the release too and keep track of the note on until released. Or would you like that we just modify the percussive to allow releases (and keep track of note on)?

But what do you propose to specify as the Pipe999 value in this case?

[eturpault]

I proposed to specify SILENT as the Pipe999 value in this case. So only the specified release sample of this pipe is played on note/key off.

[oleg68]

@eturpault Yes, I understand your suggestion, but I also want to understand the lars'es one.

[larspalo]

@oleg68 I just want to keep the functional aspect of a noise on and noise off effect in a single stop/rank. We can already work around the issue by resorting to different tricks - like looping last sample of the attack or supplying a silent attack. But what we really need as an improvement is just the possibility to specify an attack that in essence is percussive but also have a release that's also percussive (or basically a normal release). Again, there are many possibilities of how we solve this, but I think that a SILENT option for attack is not really the correct answer to the underlying need.

[oleg68]

@larspalo suppose we add a capability to specify releases for a percussive attack. How it will help us to play only release without playing the attack at all? And what attack sample we have to use in this case?

[larspalo]

@oleg68 Because @eturpault is used to specify the attack in a separate rank and the release in another. But they logically belong to the same. I usually solve the problem by looping the last sample of the attack. But a better solution to a noise stop like tracker action or stop noise is simply the ability to specify a release sample to the percussive attack sample.

[oleg68]

@larspalo Do you propose to combine two different hw sampleset ranks in the to a single go rank with OdfEdit?

[larspalo]

@oleg68 Not really. I'm proposing that we can specify the tracker action with it's note on noise and it's note off noise in one and the same rank/stop in GO. The fact that people make two different ranks for it in HW doesn't mean a thing for me. I want the logical on and off noise connected in one single rank. The other option (two ranks), one with a silent loop, or looping last sample is already available as a work around.

[oleg68]

@larspalo Implementing playing release for the percussive sample is not so easy. Now the attack/loop sample and the release sample can not sound simultaneusly: the release sample starts being played only after the attack sample is stopped. For implementing this feature we need to play attack and release independently.

[larspalo]

@oleg68 I understand that and you're spot on in the description. Also we need a way to keep track of when the release should be played without mixing on/off. For stop noises (only one pipe in the stop/rank) we can actually already use a percussive sound both on the activation and de-activation (by using an intermediate not switch). This however has currently its own drawbacks too. (Like that the off noises are also all played at organ startup, since they trigger to play anytime the stop is off...)

The workaround with having an attack and a release in the same rank/stop (either with a loop of last sample or an empty .wav) has the drawback of having a fade in the transition from on to off which muddies the off noise. Having two separate ranks partially solves this (but still you'll have a fade in of the off noise instead of it being played back as is).

Logically, the noise for a key down is tied to the noise for the key up, the noise of a stop out to the same stop in. At the same time we need them to be played independantly like a percussive for both attack and release or note on/off.

My suggestion is that we add a boolean key like NoiseEffect=Y (default N) that will do that: play the on trigger in its own sampler like a one shot and playing the release in its own sampler one shot without any crossfade between them. In other words a percussive attack and a percussive release. I suspect most work will be in altering the release part...

Or what is your suggestion to solving this?

[oleg68]

My suggestion is that we add a boolean key like NoiseEffect=Y (default N) that will do that: play the on trigger in its own sampler like a one shot and playing the release in its own sampler one shot without any crossfade between them.

@larspalo I agree with your idea. It requires some coding.

Or what is your suggestion to solving this?

I would also add a special SILENT attack sample that wouldn't prevent release from playing. But it also requires playing release independently from the attack.

[eturpault]

Why not to call this new key Pipe999ReleasePercussive for example ? The existing key Pipe999Percussive applies to the attack, the new key Pipe999ReleasePercussive would apply to the release. Playing attack and release samples independently with the same stop may be useful for another usage than noise effect.

[larspalo]

I would also add a special SILENT attack sample that wouldn't prevent release from playing. But it also requires playing release independently from the attack.

Then one could instead simply alter the DUMMY pipe to allow it to specify separate release(s), but by default not require it.

But just thinking out loud now: If the intention is to have the option to just play a sample on a release without any attack at all, then perhaps it's possible to do it like @eturpault suggests above and allow a separate definition of a Pipe999PercussiveRelease that could be independent from the percussive attack - or even existing totally without any defined attack at all. And if a percussive attack is defined too, then it's still independently managed as it is now.

As Oleg correctly points out above the real key is having the release playing independently from any attack as otherwise the crossfade into the release will always be a problem.

[oleg68]

@larspalo I'm going to introduce the key Pipe999HasIndependentRelease with a boolean value. Do you agree with this name?

[larspalo]

I'm going to introduce the key Pipe999HasIndependentRelease with a boolean value. Do you agree with this name?

@oleg68 So, we'll have to specify it for each Pipe all the time? At least, also make it available at rank level so that one can avoid that when all the pipes in that rank/stop use that feature.

[ahall41]

So I'll no longer need BlankLoop.wav (my, and Piotr Grabowski's, workaround)? :-)

[oleg68]

I'm going to introduce the key Pipe999HasIndependentRelease with a boolean value. Do you agree with this name?

@oleg68 So, we'll have to specify it for each Pipe all the time? At least, also make it available at rank level so that one can avoid that when all the pipes in that rank/stop use that feature.

Agree.

[oleg68]

@eturpault

I implemented the HasIndependentRelease and Pipe999HasIndependentRelease ODF keys as discussed above. I tested it with an artifitial samples, but, unfortunally, I don't have any real sample sets where it is really needed for noise effects.

Could you test the preview build with the samples converted from HW without a Silent pipes?

[eturpault]

Thanks @oleg68, I cannot this weekend, I will test it during next week.

[eturpault]

Here are the results of my tests with grandorgue-3.14.0-0.30.windows.x86_64, with one drawstop noise of the sample set Lędziny of Piotr Grabowski.

Test 1 : Placing in the same Stop section the attack and release samples, and adding the attribute HasIndependentRelease=Y

Percussive=N HasIndependentRelease=Y AcceptsRetuning=N Pipe001=..\OrganInstallationPackages\000690\TrakturaRej-Att\039-d#.wav ; instead of ..\SilentLoop.wav Pipe001LoadRelease=N Pipe001ReleaseCount=1 Pipe001Release001=..\OrganInstallationPackages\000690\TrakturaRej-Rel\039-d#.wav

Warnings generated by GO while loading the modified ODF :

Warning: Unused ODF entry 'Stop102/HasIndependentRelease' Warning: rank M Principal 8 Fuß noise pipe ..\OrganInstallationPackages\000690\TrakturaRej-Att\039-d#.wav: percussive sample with a release

The stop engage noise is played, the stop disengage noise is NOT played.

Test 2 : based on test 1, replace Pipe001LoadRelease=N by Pipe001LoadRelease=Y gives this result :

Warning: Unused ODF entry 'Stop102/HasIndependentRelease'

The stop engage noise is played, the stop disengage noise is NOT played.

Test 3 : based on test 1, replace Percussive=N by Percussive=Y gives this result :

Warning: rank M Principal 8 Fuß noise pipe ..\OrganInstallationPackages\000690\TrakturaRej-Att\039-d#.wav: percussive sample with a release

The stop engage noise is played, the stop disengage noise is played.

Test 4 : based on test 1, replace Percussive=N by Percussive=Y and Pipe001LoadRelease=N by Pipe001LoadRelease=Y gives this result : No warning. The stop engage noise is played, the stop disengage noise is NOT played.

Using Pipe001HasIndependentRelease=Y instead of HasIndependentRelease=Y gives the same results in tests 1 and 2 with warning :

Warning: Unused ODF entry 'Stop102/Pipe001HasIndependentRelease'

instead of :

Warning: Unused ODF entry 'Stop102/HasIndependentRelease'

Which settings permit to have both engage and disengage noises played, and no warnings ?

[oleg68]

Percussive=N HasIndependentRelease=Y

This combination is not correct. HasIndependentRelease=Y is only valid with Percussive=Y

[eturpault]

So the test 3 is the good one (HasIndependentRelease=Y and Percussive=Y) where attack and release samples are played. How to not have the warning : "percussive sample with a release" ? Maybe if there is HasIndependentRelease=Y and Percussive=Y the release of the sample should be ignored by GO ?

[oleg68]

So the test 3 is the good one (HasIndependentRelease=Y and Percussive=Y) where attack and release samples are played.

Yes. It is a right approach for noise-effect ranks.

How to not have the warning : "percussive sample with a release" ? Maybe if there is HasIndependentRelease=Y and Percussive=Y the release of the sample should be ignored by GO ?

I think if Pipe001LoadRelease=N is specified then the release tail should be ignored independent on Percussive and HasIndependentRelease values. I'll try to fix it.

[oleg68]

Did you make Pipe001LoadRelease=N in the test 3?

[eturpault]

Yes in test 3 there is Pipe001LoadRelease=N as in test 1.

[oleg68]

@eturpault I submitted a fix. Could you test again in https://github.com/oleg68/GrandOrgue-official/actions/runs/8115754748 ?

[larspalo]

@oleg68 With the build above it seems that it doesn't matter if LoadRelease is present or not for the attack. If both

Percussive=Y
HasIndependentRelease=Y

are present it just works and that's fine with me!

[eturpault]

@oleg68 with grandorgue-3.14.0-0.24.windows.x86_64 and values Percussive=Y and HasIndependentRelease=Y, there is no more warning, and attack / release samples are played correctly.

However with value Pipe001HasIndependentRelease=Y instead of HasIndependentRelease=Y, there are these warnings and the release sample is not played : Warning: Unused ODF entry 'Stop102/Pipe001HasIndependentRelease' Warning: rank M Principal 8 Fuß noise pipe ..\OrganInstallationPackages\000690\TrakturaRej-Att\039-d#.wav: percussive sample with a release.

[oleg68]

@eturpault Have you forgotten Percussive=Y ?

[eturpault]

With Percussive=Y and HasIndependentRelease=Y -> no warning and attack + release are played With Percussive=Y and Pipe001HasIndependentRelease=Y -> warnings and attack only is played With Pipe001Percussive=Y and Pipe001HasIndependentRelease=Y -> no warning and attack + release are played

[oleg68]

@eturpault I tried to fix it. Could you try https://github.com/oleg68/GrandOrgue-official/actions/runs/8132024729 ?

[eturpault]

It is fixed with grandorgue-3.14.0-0.25

[eturpault]

I implemented for the next version of OdfEdit the usage of the new attribute HasIndependentRelease at rank level for the Hautpwerk to GrandOrgue ODF conversion. The generated noise stop sections are working well with GO 3.14.0, their number is divided by 2 compared to before, and there is no more need of a file SilentLoop.wav, this is very nice.

I have a general question. How does GO decide to play the pipes of a stop section either (1) on manual keys press/release action (when the stop is engaged) or (2) on stop engage/disengage action ? Is it based on the number of pipes defined in the stop section (if there are several defined pipes GO applies the case 1, else if there is only one defined pipe GO applies the case 2) or on another criteria ?