Converting the Erfurt Predigerkirche Demo sampleset to GrandOrgue.

[oleg68]

I'm trying to convert the Erfurt Predigerkirche Demo sampleset from Piotr Grabowski ODF to Grandorgue with OdfEdit 2.1.

After opening the hauptwerk xml file and building the object tree, I can not see any Rank object in the organ.

[eturpault]

Yes I already tried to convert this sample set as well and it doesn't give good results. I plan to work on it later, it is described in a way very different from older sample sets of Piotr Grabowski. There are no Rank objects because OdfEdit doesn't detect properly the Stops objects.

[eturpault]

I analyzed this Erfurt Predigerkirche Demo sample set for Hauptwerk. In fact there are missing objects (called StopRank) to link Stop to Rank objects, so since there are no ranks associated to stops, OdfEdit doesn't create the rank objects. This doesn't seem to be normal, any other sample set that I tried have StopRank objects defined, even in the demo sample sets for the allowed stops. I contacted Piotr Grabowski to ask him why.

[oleg68]

Hi, @eturpault. I've just tried conversion of the Erfurt Predigerkirche Demo sampleset to GrandOrgue. Now all stops are here, but only Distant ranks are on file. Both Front and Rear are absent.

[eturpault]

Indeed there is this limitation. In the recent demo sample sets of Piotr Grabowski that I know (Erfurt, Düren) the link between the stops and the ranks is not done as per the specification (i.e. using an intermediate StopRank object) as it is the case in older sample sets of Piotr and in all the one of Sonus Paradisi and Augustine that I know, and which permits to have sereval Ranks linked to one Stop.
Piotr uses for Erfut and Düren an attribute called Hint_PrimaryAssociatedRankID of the Stop objet which permits to refer to one rank only, and which should be only a hint, not a functional link. With this way to design the sample set, in OdfEdit I can only do a workaround by using this hint attribute to link one rank (the close one in the case of these sample set) per stop. The ranks of the other channels (front, rear) are defined in the HW ODF but they are linked to none Stop (and none StopRank since none StopRank object is defined in these ODF), and the samples defined inside these ranks are in fact the one used by the close ranks. Inside the files of the sample set, one can see that there are pipe samples defined for a single channel, not for three channels.
So my assumption is that Piotr intentionally bridles his recent demo sample sets by offering only one channel and using a simple link between Stops and Ranks. He didn't answered to my mail so I have not got confirmation of my assumption.
In the description page of these sample sets Piotr writes :

The only limitation of demo versions is the number of available stops.

This is not completely true, he should rather write :

The only limitation of demo versions is the number of available stops and channels.

[oleg68]

Inside the files of the sample set, one can see that there are pipe samples defined for a single channel, not for three channels.

There are the samples for all six channels (3 stereo pairs):

A0_D
A0_F
A0_R

and appropriate folders for releases as well.

The ranks of the other channels (front, rear) are defined in the HW ODF but they are linked to none Stop

Could you in this case create the Rank GO ODF objects without linking to any stops? I could link them manually later using the new feature from OdfEdit 2.3.beta?

[eturpault]

You are totally right, I don't know how I can have missed these _D _F _R folders...
Yes I can create ranks in GO ODF corresponding to HW Ranks (with pipe samples inside, not with noise samples) not linked to a GO Rank. Then as you say they can be linked manually to stops in OdfEdit thanks to the new Parents or Children button.
I have just implemented it, it seems to work well. I will share a new beta release for Linux (I have first to solve an issue with my Linux virtual machine).

[oleg68]

After testing ODFEdit 2.3 with this samplesets I noted, that the compass etstension in this sampleset is wrong: there is lack of Pipe999PitchTuning lines. For example:

Pipe028Gain=1.5
Pipe028MIDIKeyNumber=63
Pipe028HarmonicNumber=16
Pipe028LoadRelease=N
Pipe028=..\OrganInstallationPackages\002524\P Pommer 4\A0_D\063-d#.wav
Pipe028ReleaseCount=4
Pipe028Release001=..\OrganInstallationPackages\002524\P Pommer 4\R0_D\063-d#.wav
Pipe028Release001MaxKeyPressTime=-1
Pipe028Release002=..\OrganInstallationPackages\002524\P Pommer 4\R1_D\063-d#.wav
Pipe028Release002MaxKeyPressTime=154
Pipe028Release003=..\OrganInstallationPackages\002524\P Pommer 4\R2_D\063-d#.wav
Pipe028Release003MaxKeyPressTime=375
Pipe028Release004=..\OrganInstallationPackages\002524\P Pommer 4\R3_D\063-d#.wav
Pipe028Release004MaxKeyPressTime=438
Pipe029Gain=1.5
Pipe029MIDIKeyNumber=64
Pipe029HarmonicNumber=16
Pipe029LoadRelease=N
Pipe029=..\OrganInstallationPackages\002524\P Pommer 4\A0_D\062-d.wav
Pipe029ReleaseCount=4
Pipe029Release001=..\OrganInstallationPackages\002524\P Pommer 4\R0_D\062-d.wav
Pipe029Release001MaxKeyPressTime=-1
Pipe029Release002=..\OrganInstallationPackages\002524\P Pommer 4\R1_D\062-d.wav
Pipe029Release002MaxKeyPressTime=223
Pipe029Release003=..\OrganInstallationPackages\002524\P Pommer 4\R2_D\062-d.wav
Pipe029Release003MaxKeyPressTime=342
Pipe029Release004=..\OrganInstallationPackages\002524\P Pommer 4\R3_D\062-d.wav
Pipe029Release004MaxKeyPressTime=504

As you can see Pipe029PitchTuning=200 is necessary, but it is missing.

[oleg68]

If will remove AcceptsRetuning=N in the next versions of OdfEdit for the pipes ranks, so some users may complain that GrandOrgue is generating the error or warning "temperament would retune pipe by more than nnn cent" for some pipes, I have to be prepared to explain them why.

1. This warning is displayed only if Strict ODF check is selected.
2. Now, retuning a pipe to a more than 600 cents produces this warning. But almost any sample sets with extended compasses usually tune some pies on one octave, ie 1200 cents.

@larspalo what do you think. Should get this warning rid, because lots of existing sample sets raise it?

[larspalo]

@oleg68 If the pitch tuning lines also are written then the warning "should" disappear as the difference between what will be adjusted by temperament and what is adjusted for the original temperament will be (should be) less (which is what I understand the warning is calculated from, not the absolute amount of re-tuning done).

As the warning is only enabled for strict odf checking, I don't think it's necessary to remove it. Also I think the warning is somewhat useful as a sample set designer to find out where errors in for instance pitch info can exist so that they might be corrected.

[eturpault]

Indeed if I disable the strick ODF checking I get no more of these logs, so this is the simplest solution to avoid them. I will give this tip if someone complains about these logs.

[oleg68]

If the pitch tuning lines also are written then the warning "should" disappear as the difference between what will be adjusted by temperament and what is adjusted for the original temperament will be (should be) less (which is what I understand the warning is calculated from, not the absolute amount of re-tuning done).

Unfortunally, now the warning doesn't take Pipe999PitchTuning into account. It looks like a bug and should be fixed.

[larspalo]

@oleg68 Something might have changed since my last experiment with lots of sample extrapolation which was done in late January this year (2023). At that time, when I re-used/stretched samples to other notes, I noticed that I got some warnings due to temperament re-tuning until I also added the Pipe999PitchTuning lines.

I don't know exactly what could/should be considered a bug in this context, but it could be a very good use case for the warning (to continue to exist) to alert if the temperament would change the pitch from the original (temperament) by a very significant amount - which might not be what a sample set designer intends, and could be a signal that an error in the pitch info might be present.

[oleg68]

Another problems are related to Pipe999MIDIKeyNumber:

1. There are wrong values in all non 8' ranks: this value must be the actual midi key if the rank was 8'. For example, for any 4' stop Pipe001MIDIKeyNumber should be 48, not 36.
2. If Pipe999MIDIKeyNumber is specifies in ODF then GrandOrgue ignores the PitchFraction value in the sample and expects the correct Pipe999MIDIKeyFraction is also specified

These problems cause incorrect working of GrandOrgue with all not equal temperaments.

I suggest not to write Pipe999MIDIKeyNumber at all when OdfEdit converts from Hauptwerk.

[eturpault]

I added the attribute Pipe999MIDIKeyNumber in OdfEdit v2.3, I found it convenient to check if the sample files are correctly assigned to the corresponding pipe999 attributes. But I admit that I am not aware about its effects in GrandOrgue. Based on your explanations, I have indeed to remove it, it will be done in the next release. Thank you for the warning about that.