Prytanee Sample set

[rousseldenis]

@eturpault I've some problems with Prytanee (full) sample set:

This is the one I have when loading GrandOrgue after OdfEdit .organ generation.

I have a lot of errors in OdfEdit put in the log file.

[rousseldenis]

Prytanee.log

[eturpault]

@rousseldenis : I suppose that some folders of the sample set where missing in your package folders, isn't it ? When you have loaded the HW ODF with OdfEdit several errors have been generated normally in such a case. Personally I use this sample set (full) without issue, but some cross fade attributes as reported in an issue.

[rousseldenis]

@eturpault ok, that's right. I just have two différent errors. How did you solve the crossfade one?

[eturpault]

By reducing the attributes causing problem for example at 45ms, as I mentioned at the end of this comment https://github.com/GrandOrgue/grandorgue/issues/1724#issue-2000461296

[rousseldenis]

@eturpault ok, didn't see they were not blocking messages.

By the way, how do you find the Cornet of Recit's tuning? Have you changed it?

[eturpault]

I have increased a little the volume of the pedal, but not made changes elsewhere.

Most of the time I use the sample set of Frankfurt that I find more versatile than the one of the Pryranée (which is great for playing the French baroque music)

[rousseldenis]

I have increased a little the volume of the pedal, but not made changes elsewhere.

Most of the time I use the sample set of Frankfurt that I find more versatile than the one of the Pryranée (which is great for playing the French baroque music)

Ok and do OdfEdit implement all the tuning features?

[eturpault]

OdfEdit converts all the HW ODF tunings for which I identified an equivalent in the GO ODF syntax. There is one known bug related to negative pipes gain : https://github.com/GrandOrgue/OdfEdit/issues/37#issuecomment-1848615457

I will list in the readme of this space the conversions which are done by OdfEdit.

[eturpault]

@rousseldenis : I have update the readme file with the detail about what is converted from HW to GO ODF. Let me know if you need more information.

[rousseldenis]

@eturpault In fact, it's really obvious the Recit's Cornet is highly detuned. Could you test it on your side in combination with Bourdon from Grand Orgue ?

I don't know if you have an Hauptwerk version to compare but sample demos on SP website are correctly tuned. If I can avoid retune it manually... :-)

[rousseldenis]

Ok, I think I've found the problem. The different layers (direct/distant/diffuse/rear) are tuned separately. Is it possible OdfEdit does not support that?

I've muted all the layers but one and the sound is better. It's like tuning different strings of a piano together (one by one it sounds good, but not together)

[eturpault]

Indeed the Cornet of the Récit has not always a nice sound. The ranks of this stop have two attack samples. What I observe is that if one repeats the press on the Do3 for example, sometimes the sound is good some other times it is detuned, I think that one of the two attack samples of some layers is detuned. I don't have Hauptwerk installed on my computer, I cannot compare.

The samples of the various layers are stored in separate ranks, OdfEdit converts all the ranks of the HW ODF independently of each other, and they are rendered as they are by GrandOrgue. In the HW ODF syntax there is no attribute to correct the tuning of one sample compared to other samples of the same pipe. So I don't see how to avoid this detuning of some samples.

[larspalo]

I think that one of the two attack samples of some layers is detuned. ... In the HW ODF syntax there is no attribute to correct the tuning of one sample compared to other samples of the same pipe. So I don't see how to avoid this detuning of some samples.

If two attack samples in the same rank are heavily detuned without a specific reason it could be considered as a "bug" in the sample set itself. Perhaps somewhat poor processing of the samples from the producer, or that something is lost/changed in the conversion of the sample set.

Almost ten years ago I had a discussion with Martin about how GO handles the pitch information (can still be found at https://sourceforge.net/p/ourorgan/mailman/ourorgan-developers/?viewmonth=201402 from the 17th and forward a few days) and at that time I was in favor of having GO respect individual pitch info for every attack in a pipe.

Later I've changed opinion as so much can potentially be lost by that approach (the natural de-tune when using tremulants in temperaments, true re-creation of undulating stops like célestes in temperaments already is much more difficult, the subtle effect of using multiple attacks could be reduced, just to name a few examples). And honestly, if the pipe(s) are sampled at the same time, the need for individual pitch adjustments for individual attacks normally shouldn't really be there as they are all coming from the same pipe(s) anyway and all adjustments done should be equal for all of the attack versions of it to preserve the original character of the organ as much as possible.

The samples of the various layers are stored in separate ranks

That shouldn't be a problem though, as they can be adjusted properly at that level (rank/pipe). Is the tuning better in a selected temperament than what it is in "Original"? If so, it would indicate that the PitchTuning perhaps needs to be improved.

For the Prytanee sample set there seems to be some tuned samples for some of the stops/ranks that should most likely be used instead of the original samples - not as the same pipe, but replacing them, if the user select/activate a switch for it. If both versions (original and tuned) are put in the same pipe there could very well be issues like @eturpault mentions above.

[rousseldenis]

@larspalo following the features description of the sample set, it has only features to extend the keyboard from 49 to 54 keys. So, how HW treats the sample set to render it correctly?

I already tried to change the temperament and it has no influence on the tuning.

[larspalo]

@rousseldenis I don't have the complete sample set, and I don't know for sure, but I did notice that there is a folder/directory named "OrganInstallationPackages/002300/MixtTuned" that has "Echo_Recit", "GO" and "Positif" subdirectories, that in turn has different rank folders/directories that contain other samples than in the normal "pipes" folder/directory. Also there's a "mixturestuning" directory that has bmps for tuning on/off.

All that leads me to suspect that when activating a tuning option, the samples in the MixtTuned subdirectories will replace the normal samples - not that they are added as additional attacks. Not knowing anything about the original full HW odf or even how the OdfEdit converted odf looks like, I'd just suspect that there are mixed versions of samples in the same pipe. I could be wrong, though...

[eturpault]

This sample set has a "Pipe coupling level" slider in the Mixer panel. It is described like this by the Sonus Paradisi web site :

The slider for the pipe coupling makes the effect more prominent (more distuning) when up, or less (when down). If the lowest position, the effect is switched off.

This feature is not converted by OdfEdit in the GO ODF. OdfEdit converts only the standard samples which are defined in the ranks of the HW ODF.

[larspalo]

OdfEdit converts only the standard samples which are defined in the ranks of the HW ODF.

If that's true and no misunderstanding has happened, the only way is to manually examine each attack (for any pipe that's off) and find the one (attack) that's "wrong" and remove that from the pipe so that no vastly different samples exist in one single pipe.

[eturpault]

The samples of the folder MixtTuned are not used in the HW ODF (full surround version).

[rousseldenis]

This sample set has a "Pipe coupling level" slider in the Mixer panel. It is described like this by the Sonus Paradisi web site :

The slider for the pipe coupling makes the effect more prominent (more distuning) when up, or less (when down). If the lowest position, the effect is switched off.

This feature is not converted by OdfEdit in the GO ODF. OdfEdit converts only the standard samples which are defined in the ranks of the HW ODF.

@eturpault yes, I saw that but it says that's only for amplitude and not tuning. How to know if the tuned samples can be activated?

@larspalo I suppose SP wanted to put the raw samples in his work and use HW feature to get the tuned version. So, less studio work

[rousseldenis]

@eturpault it seems that all wav files suffixed by '_050' in Cornet are detuned and not the normal ones (e.g.: 060-c.wav).

I see that those not suffixed by 050 are loaded by OdfEdit as first attack file. But I think attack files are located in folders suffixed by '_tr'.

I will try replacing 050 files by normal ones.

Is it possible those files are those activated by the fine tuning button?

[rousseldenis]

@eturpault I get a good tuned sample by renaming all the _050.wav files to .wav in the ODF. I think this is not a long term solution.

IMHO there should be something in the HW xml that define how the button 'Fine Tuning' is acting or there should be something else that uses those 'normal' files but I don't know the HW structure.

Could you check that ?

[eturpault]

@rousseldenis This is an interresting use case. I have studied the HW ODF around this topic, here is what I found. Folders suffixed by "_tr" contain all and only tremmed samples files (both attacks and releases). Sample files suffixed by _050 are all used as second attack for following stops (non tremmed only), whereas the non _050 files are used as first attack :

• POS Cymbale / Fourniture,
• GO Cymbale / Fourniture / Cornet,
• REC Cornet,
• ECH Cornet

OdfEdit converts the _050 files either as first or as second attack sample, this is not good, I have just implemented an improvement so that the order of samples definition of the HW ODF is reflected in the GO ODF as well. With this I have now in the GO ODF the _050 files all defined as second attacks only. In the definition of the _050 samples in the HW ODF, there is an additional attribute compared to the non _050 samples, it is named AttackSelCriteria_HighestCtsCtrlValue, It is set at 50 for all these samples (certainly a link with the _050 of the files names) and is used only for these _050 files. HighestCtsCtrlValue means Highest Continuous Control Value. A continuous control is like a slider control in HW ODF (which can be an internal control, not necessarily visible, whereas a switch is a non continuous control).

In the panel "Mixer and Noise", there is a switch named "Tuning Selection" (displayed as "Mixtures tuning" in the panel) permitting to choose between original tuning (switch disengaged) and fine tuning (switch engaged). It controls the state of a continuous control having the value 127 when the switch is disengaged (default value), and I suppose 0 when the switch is engaged. I guess that AttackSelCriteria_HighestCtsCtrlValue=50 means that if the continuous control has a value lower or equal to 50 (so if original tuning is selected) the second attacks (files _050) can be selected by the audio engine, else they cannot be selected. I think that the first attacks can be always selected as I don't see a selection condition for them.

Now the problem is to convert such a mechanism in GO ODF. IsTremulant attribute permits to select or not a sample based on a on/off state, and it is already used for the Tremulant. AttackVelocity permits also to select or not a sample based on the key press velocity. I don't see another attribute which would permit to select or not a sample based on an on/off state. So I don't see how to convert in GO this sample selection mechanism. @larspalo would you have an idea ?

[eturpault]

For information, in a HW ODF, here are the effects on a pipe which can be controlled by a continuous control :

• attack selection
• release selection
• amplitude (already used by OdfEdit)
• pitch scaling
• pitch increment
• harmonic shaping increment

At samples level, the attack or release sample selection can be controlled by :

• highest continuous control value (continuous control defined at pipe level above)
• minimum time since previous pipe close (in ms)
• highest velocity
• latest key release time (in ms, for release only, already used by OdfEdit)

For the enabling/disabling of the original tuned samples of Prytanée (files _050), should it be possible to have a new attribute like Pipe999Attack999Switch=NNN, if the SwitchNNN is engaged, the attack sample can be played, else it cannot be played ? The switch could be also a tremulant switch or any other kind of feature which the audio effect is enabled/disabled by a switch.

[larspalo]

For the enabling/disabling of the original tuned samples of Prytanée (files _050), should it be possible to have a new attribute like Pipe999Attack999Switch=NNN, if the SwitchNNN is engaged, the attack sample can be played, else it cannot be played ?

There is a much simpler solution that requires more RAM usage but will work with GO as it currently is. A switch could easily control if one stop or another would be acvtivated, right. So, two ranks with (perhaps only slightly) different pipes can be used by two different stops both needing the same "activating" visible switch but in cooperation with another "selecting" switch (or switch and NOT version of it) can already easily be added to decide which set of pipes will be active.

In the future it might indeed be interesting to have CC control over different pipe/attack/release attributes, but it would be sometime in the future whereas a simple user selecting operation can already be implemented.

Velocity is already available in GO as a selection criteria. However, there is currently a "flaw" in the attack selection with velocity: the attacks available for selection is cumulative from the lower velocities to the higher. That is - you cannot currently exclude a low velocity attack for a high velocity key strike, but you can exclude a high velocity demanding attack from a low velocity key strike. This is something I think should eventually be corrected, but for now it is how it works.

[eturpault]

Ok thanks @larspalo for the suggestion. So I have to group these special samples in dedicated stops/ranks, controlled by an additional switch, this is quite similar to tremmed samples management finally (when they are stored in their own rank). I will implement this, some hours of coding to come :smiley:

[larspalo]

I will implement this, some hours of coding to come 😃

Yes, certainly! But usually it's very satisfying when it finally works! Thanks for your effort!

[rousseldenis]

Ok thanks @larspalo for the suggestion. So I have to group these special samples in dedicated stops/ranks, controlled by an additional switch, this is quite similar to tremmed samples management finally (when they are stored in their own rank). I will implement this, some hours of coding to come 😃

Thanks @larspalo , I thought about it but didn't know if it is possible to automate the process in OdfEdit easily

[eturpault]

@larspalo, you wrote :

Velocity is already available in GO as a selection criteria.

Do you have in mind these attributes ? :

• Pipe999AttackVelocity=(integer 0 - 127, default: 0) minimum velocity to use this attack sample.
• Pipe999Attack999AttackVelocity=(integer 0 - 127, default: 0) minimum velocity to use this attack sample.

In the HW ODF, the attribute is named : AttackSelCriteria_HighestVelocity, it seems to be defined at 127 by default, so it is the opposite definition of the GO definition. The conversion from HW to GO would be : Pipe999AttackVelocity = 127 - AttackSelCriteria_HighestVelocity, have you the same understanding ?

[larspalo]

The conversion from HW to GO would be : Pipe999AttackVelocity = 127 - AttackSelCriteria_HighestVelocity, have you the same understanding ?

Yes, it's possible that the HW velocity selection works completely in the opposite way from GO, I know too little about it to say for sure, but your calculation seems to be a sound way to transfer the raw values to something usable.

For the future, I personally think that we would need both a high (max) and low (min) velocity limit in GO to be able to truly differentiate between attack choices purely on velocity - currently there will always be a random element mixed into the selection too.

[eturpault]

I studied the possibility to convert from HW to GO ODF the fact that attack samples of a pipe can be selectable based on a switch state. The configuration defined in the HW ODF is the following : a pipe has two attack samples, the first attack is always selectable, the second attack is selectable only if a switch is engaged. If the switch is not engaged, only the first attack can be played for this pipe. If the switch is engaged, one of the two attacks can be played for this pipe, selected randomly, but the two attacks are not played simultaneously.

As @larspalo suggested, this may be converted in GO ODF by spliting the rank in two ranks, one rank with the first attack of each pipe, the second rank with the two attacks of each pipe, and having a switch mechanism to select one rank or the other rank based on an additional switch state. It is tricky to implement, and as this configuration is used only to introduce detuned attacks which are not pleasant to hear, and few sample sets are using it (I identified only Sonus Paradisi Buckeburg, Este, Prytanée and Rotterdam having this feature among the 30 HW sample sets installed on my computer from various editors), I think it is not worth to manage this use case. What I will implement in OdfEdit v2.10 is to ignore these attacks during the HW to GO conversion. If one day GrandOrgue gives the possibility to make an attack selectable based on the state of a switch (additionally to the existing criteria : tremulant state, attack velocity, maximum time since last release) it will be worth to convert the configuration described above.

[eturpault]

Fixed in OdfEdit v2.10 by not converting the samples which the attack selectability is based on a continuous control state, this permits to exclude the detuned samples.