Tremulant features in ODF

[oleg68]

Often there are separate ranks with tremmed and not-tremmed samples in HW samplesets. For converting them to GO format it is necessary to add Pipe999IsTremulant value for each pipe,

Allowing to set IsTremulant at the rank level would simlify converting HW to GO ODFs.

[larspalo]

The only objection to this is that it would be a deviation from the real organ model. A pipe that's affected by a tremulant cannot exist separately from it's non tremulated version - that is: the tremulant affected pipe is not really a rank by itself it's just another version of the same pipe that's modified by the active tremulant(s). (unless of course there's no way to turn off the tremulant in question and you cannot have the pipe in an un-tremulated version, ever)

[oleg68]

The only objection to this is that it would be a deviation from the real organ model. A pipe that's affected by a tremulant cannot exist separately from it's non tremulated version - that is: the tremulant affected pipe is not really a rank by itself it's just another version of the same pipe that's modified by the active tremulant(s)

I can not agree with this reason because current ODF syntax does not allow to assign several samples (tremulated and not) for the single pipe

Pipe1NonTremulated=sample1.vaw
Pipe1Tremulated=sample2.vaw

The only way to do this now is to make two ranks. So Pipe999IsTremulant (that is also a deviation from the real organ model) has less reasons for existance than the rank-level IsTremulant.

[larspalo]

I can not agree with this reason because current ODF syntax does not allow to assign several samples (tremulated and not) for the single pipe

Pipe1NonTremulated=sample1.vaw Pipe1Tremulated=sample2.vaw

The only way to do this now is to make two ranks. So Pipe999IsTremulant (that is also a deviation from the real organ model) has less reasons for existance than the rank-level IsTremulant.

No, this is not true! I'll show you below how this is supposed to be done:

Pipe001=./OrganInstallationPackages/000869/pipe/GO_voxhumana/036-C.wav
Pipe001IsTremulant=0
Pipe001LoadRelease=N
Pipe001AttackCount=1
Pipe001Attack001=./OrganInstallationPackages/000869/pipe/GO_voxhumana_trem/036-C.wav
Pipe001Attack001IsTremulant=1
Pipe001Attack001LoadRelease=N
Pipe001ReleaseCount=6
Pipe001Release001=./OrganInstallationPackages/000869/pipe/GO_voxhumana_trem/rel00190/036-C.wav
Pipe001Release001MaxKeyPressTime=190
Pipe001Release001IsTremulant=1
Pipe001Release002=./OrganInstallationPackages/000869/pipe/GO_voxhumana_trem/rel00390/036-C.wav
Pipe001Release002MaxKeyPressTime=390
Pipe001Release002IsTremulant=1
Pipe001Release003=./OrganInstallationPackages/000869/pipe/GO_voxhumana_trem/rel99999/036-C.wav
Pipe001Release003MaxKeyPressTime=-1
Pipe001Release003IsTremulant=1
Pipe001Release004=./OrganInstallationPackages/000869/pipe/GO_voxhumana/rel00190/036-C.wav
Pipe001Release004MaxKeyPressTime=190
Pipe001Release004IsTremulant=0
Pipe001Release005=./OrganInstallationPackages/000869/pipe/GO_voxhumana/rel00390/036-C.wav
Pipe001Release005MaxKeyPressTime=390
Pipe001Release005IsTremulant=0
Pipe001Release006=./OrganInstallationPackages/000869/pipe/GO_voxhumana/rel99999/036-C.wav
Pipe001Release006MaxKeyPressTime=-1
Pipe001Release006IsTremulant=0

Understand that we're still talking about one pipe! One pipe in one rank. One physical pipe == Pipe001. Then that same pipe has another attack and three releases defined to be affected by a tremulant (besides the one attack and three releases not affected by a tremulant). It's still one pipe. If you create two different ranks you most likely create two different physical pipes - unless you borrow the pipe of course but that's another thing.

[larspalo]

But as a side note: it's indeed already possible to create two different ranks from the tremmed and non-tremmed samples and select between them (with a switch) but you'll loose the transition between the different samples on a held note when you do the switch between them. With the proper method I illustrated above you'll have a transition on a held note correctly.

[oleg68]

I illustrated above you'll have a transition on a held note correctly.

You do not use Pipe999IsTremulant

But Pipe999IsTremulant exists. Why it is better than IsTremulant for a rank?

[larspalo]

You do not use Pipe999IsTremulant

Yes, but it's set to
Pipe001IsTremulant=0
then another attack (supposed to be triggered under different circumstances) have
Pipe001Attack001IsTremulant=1

Why it is better than IsTremulant for a rank?

Because this pattern (I illustrated above) shows how the organ works. You have one pipe in one rank (accessible from one drawstop) that can be affected by another drawstop that is a tremulant. It's still anyway one and the same pipe, the tremulant usually works by just disturbing the wind supply to the pipes creating fluctuations both in amplitude and pitch.

[oleg68]

Pipe001IsTremulant=0
then another attack (supposed to be triggered under different circumstances) have

Why not

Pipe001AttackCount=2
Pipe001Attack001IsTremulant=0
Pipe001Attack002IsTremulant=1

?

In this case One physical pipe would have several sounds variant.

And the same with multichannel sound:

Pipe001ChannelCount=2
Pipe001Channel001=front/036-C.wav
Pipe001Channel002=rear/036-C.wav

[larspalo]

No, that's not how it works. You first define a pipe, then you add additional attacks to it. The point actually is that one single pipe in the rank only can sound in one way at a given time. You can have multiple versions to choose from but only one can sound at a time.

For multichannel (as we discussed in another issue) there's another solution that's easy and efficient in re-creating the virtual experience of the different microphones.

[oleg68]

No, that's not how it works. You first define a pipe, then you add additional attacks to it.

Yes, I understand it. But why to put Pipe999IsTremulant=0 for all pipes if it is always=0 and never is=1 for pipe in this pattern? Isn't better to do this at the rank level?

[larspalo]

Still no. And, yes, it's =1 for some in that pattern, look again - but it's for the additional attacks. It could be defined in other ways and it would be perfectly valid anyway. Why I did it like I did above is that de first defined attack is what I consider to be the "default" and the tremmed as an additional attack. But yes, it could be done the other way around and the ODF would be valid and it would work as you'd expect. I did it like that just because I consider the non-tremmed version to be the pipe on it's own and the additional tremmed as the pipe with a tremulant.

If you do it on a rank level you're implying that this rank of pipes is always affected by a tremulant, it doesn't have any other state. And it might be true! But I've never seen anything like that in real life though, except when an organ has malfunctioned...

[oleg68]

Still no. And, yes, it's =1 for some in that pattern, look again - but it's for the additional attacks

In this pattern all pipes always have IsTremulant=0 and all (additional) attacks always have IsTremulant=1

My suggestion is to set IsTremulant=0, AttackCount=1, Attack001IsTremulant=1 at the rank/windchest/organ level instead of the individual pipe level. The same for releases.

[oleg68]

If you do it on a rank level you're implying that this rank of pipes is always affected by a tremulant, it doesn't have any other state. And it might be true! But I've never seen anything like that in real life though, except when an organ has malfunctioned...

No. In my suggestion Rank Level values are just default values for all pipes.

[larspalo]

You can mix and match them in anyway you want to. You can define the base pipe IsTremulant=1 and additional Attack001IsTremulant=0. It's quite possible, though I prefer it the other way around just for logic.

As it's written in the help the values for IsTremulant are:

(int -1 - 1, default: -1) 1 means, that it is played, if the associated wave-based tremulant is on. 0 means, that it is played, if the associated wave-based tremulant is off. -1 means, that it is not affected by a wave-based tremulant.

No. In my suggestion Rank Level values are just default values for all pipes.

I feel we must have a basic organ knowledge course here! ;-)

A rank is a line of pipes (physical) that's usually placed on the soundboard of the windchest (occationally not, but that's more a case of exception - like when the facade pipes are conducted away from the windchest). You should never define a rank of pipes that doesn't actually exist as such in the organ, the only exception to this is the multichannel scenario which in itself is an unreal situation - a human only has two ears that can be in one place at a time to listen to the organ, whereas the microphones can be placed at any multiple places when recording as long as you have more than one.

Thus, if you define a rank constructed with only tremmed samples they are not the default. They are the only ones.

[oleg68]

@larspalo

Now I'm not suggesting to have two separate ranks. I want to have only one rank according to your pattern, but to write ODF simpler: to move the repeating values from the pipe level to the rank level.

And not only for tremulants.

Another example: if each pipe has recorded with three releases, and the first release of each pipe has MaxKeyPressTime=180, the second one - 360 and the third - -1, then not to repeat

Pipe999LoadRelease=N
Pipe999ReleaseCount=3
Pipe999Release001MaxKeyPressTime=180
Pipe999Release001MaxKeyPressTime=360
Pipe999Release001MaxKeyPressTime=-1

for each pipe but to tell GO that all pipes in the rank has the same release pattern.

[larspalo]

to tell GO that all pipes in the rank has the same release pattern

That is another issue, that might have it's uses as a shortcut - I must think on that. I think I begin to understand where you're going with this issue and I'm not sure this is necessarily the right way, though.

For the original issue - isTremulant on a rank level means in reality not that much, even expressed like that. For the end user nothing really, and for the ODF creator very little time saving especially if one uses tools for ODF creation or even simple copy/replace/paste in a text editor. What you're assuming is that every pipe for that rank will have exactly the same amount of attacks and releases presented in exactly the same layout, and while it might be true in most cases it's certainly not always like that. You're in essence thinking of ways on how to reduce the amount of lines necessary to write in the ODF if the pattern truly is repeating.

An effect of this is that you're adding information for the rank that's not a description of the organ but an instruction for reading a shorthand writing of the information to come. Personally I'd happily sacrifice the possible convenience for the ODF creator for more pure organ model. For the ODF creators we should have better software available that produces quality ODF outputs instead, while still being easy to use.

Regarding the Pipe999 and Pipe999Attack999 the model thought is to have the default attack sample as Pipe999 and additional/alternative attacks separately. It impacts choice of attack loading for one thing but that's perhaps of minor importance.

[oleg68]

@larspalo Can I make a single switch for two tremulants in ODF?

[larspalo]

That should absolutely be possible. But please elaborate on the background and how you want them to behave. What two tremulants are you thinking about, the synthed and the sample based? For one or many ranks/stops?

While we're talking about tremulants - I do think that it would be very nice to have a synthed tremulant able to impact pitch (and not only amplitude as it's presently doing) ref #709. We just need to be aware that everything we do will reduce available polyphony. Just like I do want to implement a swellbox model according to #717 but it will also reduce polyphony - but the increased realism from the current amplitude only based version is hugh.

[oleg68]

What two tremulants are you thinking about, the synthed and the sample based?

Yes, I am.

For one or many ranks/stops?

For many ranks in one division. Some of them ranks have tremulated samples, some - do not. A single switch should enable/disable tremulation for all the ranks.

[larspalo]

Put the ranks for that division on two different windchestgroups (like for instance one SwellSynthed and one SwellSampled) that each have a (non displayed) tremulant of appropriate kind. Have both the tremulants activated by the same (displayed) switch. Then it should work so that the (synthed) tremulant only affects the correct ranks.

PS. Having multiple windchest groups for a division is not problematic from the real world organ perspective. It was commonly used by for instance Cavaillé-Coll to vary the windpressure given to the pipes. Not to mention the basic Fonds vs Anches windchest separation within the same division.

[oleg68]

that each have a (non displayed) tremulant of appropriate kind. Have both the tremulants activated by the same (displayed) switch.

1. How to make a remulant non displayed?
2. How to make a tremulant activated not by an it's own button, but by a switch?

[larspalo]

1. By default the [Tremulant999] will be non displayed. You have to actively display it. (Just remove Displayed=Y if necessary)
2. Add under [Tremulant999]

Function=And
SwitchCount=1
Switch001=999

The switch you point to should be the same for both tremulants. The switch should of course be displayed.

[oleg68]

@larspalo thank you. I'll try it.

[oleg68]

@larspalo I implemented the switches as you suggested. The tremulants seems work.

But the switch state is not remembered in the combinations setter. May be I misssed something?

[larspalo]

Not sure what's the problem as I cannot see the odf and test it. Maybe check if you have a false value of CombinationsStoreNonDisplayedDrawstops in the [Organ] section. Otherwise, I attach a very small sampleset demonstrating the setup, that you can study. I can program the setter with the tremulant as you can see yourself (combinations 0-5 is already set).

However, if you want to be able to store a switch in divisionals it must also be registered under the manual. And in the odf generals the switch must be listed too if it should be stored.
OneTremToRuleThemAll.zip

[oleg68]

Thank you, @larspalo. I've tested the switches and it works with combinations.

The problem waw with the old preset and the combination files. After I made the new preset and I loaded, retrieve and set the combinations with the correct switch state, the new combination file remembers it.

[midimusic]

In order to get a realistic tremolo it is necessary that the tremolo modulation is IN PHASE for all pipes of a particular rank. This is not possible with tremmed samples. But it is possible if you use a synthesised trem on non tremmed samples. Thus the synthesised trem is always the best option if you want a realistic organ sound from a tremmed rank.

csw900