GrandOrgue missing features

[rousseldenis]

I want to add here some ideas about features that are missing in GrandOrgue.

As first entry point, I've copy/paste the points Piotr Grabowski mentioned on his GrandOrgue page (https://piotrgrabowski.pl/grandorgue-versions/):

• As I don’t use GrandOrgue packaging format, installation process is not as easy as with Hauptwerk. For my newer sets it requires basic knowledge about extracting RAR archives and moving files to make proper folder structure. Detailed instructions are shown in the paragraph below.

• Patching the sample sets won’t be easy as with Hauptwerk and that’s the reason I will wait with every GrandOrgue release to be sure that current Hauptwerk package is rather final, patched version. Patches listed on sample set page can’t be easily applied to GrandOrgue versions.

• Still few years after my first GrandOrgue releases, scalling of the user interface is still counter-intuitive. It doesn’t automatically fit display resolution. I still have to release two versions, which differ in size of graphical user interface.

• My new sample sets come in multichannel format. You may not have enough memory to load entire sample set, then you can disable ranks or whole audio groups from loading in Audio/Midi / Organ settings window by selecting on the left tree items you don’t want to load and then switch on the right side Sample channels option to Don’t load. To access Organ settings window you need to load the sample set or break the loading process once it passes Parsing sample set definition file phase.

• In the same Organ settings window you can assign different ranks to different audio groups (audio outputs). You can manage audio groups in Audio/Midi / Audio/Midi settings window, in Audio groups tab.

• Scaling of graphic interface is not working very well, so scaled interface will cause some misalignements.

• For newer sets, in Panel / Sample set settings you can adjust audio levels of different elements (audio groups, divisions, key/stop noises). It is not easy to change these values, but it is possible. When you click the value with left mouse button, it will usually set to rather random value, then use mouse scroll to select desired value and then release left mouse button. These values operate in 1-100% range (despite visible 0-100% range), as I disabled 0% value, because setting this value to 0% was disabling all currently playing sounds (pipes, blower noise, ambient noise etc.).

• Sample sets volume is normalized to the default GrandOrgue setting, which is -15dB, so playing a big chord with all stops engaged shouldn’t distort audio output with this value set.

• Some sample sets lack of features, which are present in Hauptwerk versions e.g. combination system in Szczecinek, Orage in Oloron-Sainte-Marie, enclosure pedal noises.

• Setting any temperament (other than original) results in retuning whole organ to a1=440 Hz, so e.g. for Erfurt Büßleben it results in retuning whole organ by 3 semitones.

• All of the percussive stops, which originally have dampeners (like Campane stop in Alessandria sample set) due to GrandOrgue limitations, sound quite unnatural, as the crossfade between the sustaining part and the silence is too short.

I didn't reviewed those points as I first wanted to put raw data (except the two last lines as they don't speak about features).
The idea here is to help improving GrandOrgue from feedbacks of sample set designers, users, ...

@oleg68 Maybe you can answer on some points if they are in GrandOrgue already.

[oleg68]

@rousseldenis Most of all the points are not missing features, they are just a hint for the user how to use GrandOrgue.

Scalling works now.

We don't have a feature for using pitches other than a1=440 Hz for not original temperaments now. It can be easy added.

[rousseldenis]

@rousseldenis Most of all the points are not missing features, they are just a hint for the user how to use GrandOrgue.

Scalling works now.

We don't have a feature for using pitches other than a1=440 Hz for not original temperaments now. It can be easy added.

Yes. But they are points that refrain him to release sample sets in GrandOrgue format. Maybe we can answer each one that can lead to re-addopt it?

[rnditdev]

Lets work on Piotr's points one by one, and try to reach him with answers.

[eturpault]

A solution would be that GrandOrgue is able to load and play sample sets made for Hauptwerk. So the GrandOrgue users would have access to very much more choice of organs sample sets than today, and the sample set editors would gain a lot of new customers with the GrandOrgue users community.
Looking at the Hauptwerk SW and the sample set editors EULA (end-user licence agreement) documents, it seems that it is not prohibited to use a sample set made for Hauptwerk in another VPO application, especially if we don't make modification in it.
I am working since months on an evolution of my tool OdfEdit which, from a sample set made for Hauptwerk, generates an ODF (organ definition file) permitting to load and play this sample set with GrandOrgue, without modifying anything in the sample set. For sure it will not permit to retrieve in GrandOrgue all the sound quality and controls capabilities that Hauptwerk can offer, but it should permit to play this organ with the level of quality and controls that GrandOrgue is able to ensure.
I have still a lot of work to do before to complete this task (if I succeed to do it), but currently I already get promising results.

[eturpault]

I pushed in the repository https://github.com/GrandOrgue/ODFEdit/tree/main/bin the binaries (Windows and Linux) of my new version of the OdfEdit tool v2.0 which adds the Hauptwerk to GrandOrgue ODF conversion.
Here are the steps to use it :

• unzip a Haupwerk sample set (not encrypted) in the disk of your computer
• launch OdfEdit
• click on the button "Open" then select the organ definition file (extension .Organ_Hauptwerk_xml, located in the folder OrganDefinitions of the sample set package) of the Hauptwerk sample set that you want to play with GrandOrgue. OdfEdit will create a GrandOrgue ODF located in the folder OrganDefinitions, having the same name as the Hauptwerk ODF and the extension .organ.
• load this new .organ file in GrandOrgue, and enjoy !

Some functions of the organ are not yet supported by the v2.0 : enclosure, tremulant, noises (stops, keys, blower, ...), combinaisons, conditional switches. I am working to add them progressively in next releases.

I tested it with the following sample sets, and I can play them with GrandOrgue :

• Augustine - Dreischor
• Augustine - Lorris
• Sonus Parasidi - Martini demo
• Sonus Parasidi - StMichel demo
• Piotr Graboswki - Ernelo demo
• Piotr Graboswki - Ledziny
• Piotr Graboswki - Skrzatusz

When loading some sample sets in GrandOrgue, the following warning can occur :
Warning: "Filename '%s' not compatible with case sensitive systems"
This is caused by the fact that some characters in the files path or name have not the same case between the ODF and the package. To fix this, simply change in the ODF or in the package the case of the characters which are causing the warning.

Another warning can occur :
Warning: iCCP: known incorrect sRGB profile
Solution : open each image causing the warning with for example IrfanView or FastStone Image Viewer and then resave the image.

With the sample sets of Augustine the transparency is not well managed around the stops or combinaisons buttons. I don't know why, maybe it is linked to the .png files properties.

If you encounter errors please open a discussion here : https://github.com/GrandOrgue/ODFEdit/discussions and give me the name of the sample set and where it can be downloaded.

[oleg68]

Merry Christmas! Thank you for your great job!

I tried to convert the Buckeburg sample set from Sonus Paradisi. Unfortunally, all PipeXXX and PipeXXXReleaseYYY values were imported as None, and I receive a lot of errors File 'None' does not exist when I'm trying to load it with GrandOrgue

[eturpault]

Hi @oleg68, Merry Christmas to you as well ! Thanks for the feedback, I will look that this sample set and will fix the issue, I see that it is an interresting configuration. I will need probably several rounds before to support the various possible organ definitions, based on the feedbacks that I hope to receive.

[eturpault]

Hi @oleg68, I don't reproduce your issue with the sample set Buckeburg from Sonus Paradisi. While loading in GrandOrgue the file "Buckeburg, Janke Organ, Surround Demo.organ" generated by OdfEdit, I get a lot of warnings "Filename '%s' not compatible with case sensitive systems" due to the fact that most of the images have the extension .BMP in the package, whereas they are defined with the extension .bmp in the ODF (which can be fixed with a files renamer tool), but the ranks of the ODF are all containing valid files names, like for example below, and I can load the sample set and play all the stops without problem.

[Rank003]
Name=Front (Diffuse): Ped Subbass 16
NumberOfLogicalPipes=32
FirstMidiNoteNumber=36
Percussive=N
AcceptsRetuning=N
WindchestGroup=006
Pipe001Gain=0.9
Pipe001HarmonicNumber=4
Pipe001LoadRelease=N
Pipe001=..\OrganInstallationPackages\002306\pipes\Buckeburg_1noc_PED\Ped_Subbass16\03-AB_Ped_Subbass16\036-C.wav
Pipe001ReleaseCount=3
Pipe001Release001=..\OrganInstallationPackages\002306\pipes\Buckeburg_1noc_PED\Ped_Subbass16\03-AB_Ped_Subbass16\rel00450\036-C.wav
Pipe001Release001MaxKeyPressTime=439
Pipe001Release002=..\OrganInstallationPackages\002306\pipes\Buckeburg_1noc_PED\Ped_Subbass16\03-AB_Ped_Subbass16\rel00220\036-C.wav
Pipe001Release002MaxKeyPressTime=209
Pipe001Release003=..\OrganInstallationPackages\002306\pipes\Buckeburg_1noc_PED\Ped_Subbass16\03-AB_Ped_Subbass16\rel99999\036-C.wav
Pipe001Release003MaxKeyPressTime=-1

Which logs do you have in the Logs tab of OdfEdit ?
What you have should occur if the folder "OrganInstallationPackages" of the sample set doesn't contain the expected package folder (002306 for this sample set).
In case you still have issues to generate a correct ODF file with OdfEdit, here is the one that I generated and which works well in my side : Buckeburg, Janke Organ, Surround Demo.zip

[oleg68]

I started a discussion at GrandOrgue/OdfEdit#7

[newVideophile]

Ok, so this is the Christmas post ;-)

Here is my list (rather short because I find GrandOrgue nearly perfect for my need):

• A "General Cancel" and a "Setting" button in the main menu window for faster access
• Larger main menu window with larger buttons
• Windows positions memorization; currently, all windows open at the center of the screen, so you must move them again each time you open GrandOrgue (in Windows 10 at least)
• A timeline while playing a midi file to be able to jump directly to any position (like the red timeline in YouTube)
• More MIDI controlled features; for example, I would like to control the Reverb gain and/or length through MIDI, using a physical interface (e.g. a MIDI slider, rotating knob, etc.)
• An "auto-save on exit" option
• Organ loading time optimization; for obscure reasons my Windows 10 laptop is approximately twice a slow as my Raspberry Pi to load the same Friesach organ with the same settings (cache, bit depth, loops loaded, etc.), while it is supposed to be several times faster from both a CPU and HDD standpoint (both systems have 8 Gb of RAM, though)

[rousseldenis]

• Windows positions memorization

This is already the case. Per organ. When your windows positions are ok, click on Save settings. Next time, windows positions are restored.

• An "auto-save on exit" option

This is now possible. If some settings are modified, if you try to quit, a popup will ask you if you want to save modifications (auto-save is too risky)

[newVideophile]

• Windows positions memorization

This is already the case. Per organ. When your windows positions are ok, click on Save settings. Next time, windows positions are restored.

Well, I re-did the test, it doesn't work for me...

• An "auto-save on exit" option

This is now possible. If some settings are modified, if you try to quit, a popup will ask you if you want to save modifications (auto-save is too risky)

In this case, why not replace "some" by "all"? If I select a stop and quit, I don't get any popup and the stop is not select when I start GrandOrgue again (but of course it is if I save before quitting). I also tried to change the Reverb gain, no popup. But in this case, the change was memorized.

Tests done with v3.9.0-0.9

[ahall41]

• my Windows 10 laptop is approximately twice a slow as my Raspberry Pi to load the same Friesach organ

The problem might be NTFS. I noticed that my laptop (dual booting Windows and Linux Mint at the time) was noticeably slower to load an organ under Windows. And Linux is also slower when the organ is on an NTFS partition rather than the EXT partition I was using on Linux. I was testing out HW at the time, and gave up on Windows. Linux has slightly more RAM to spare too.

[rnditdev]

I just want to say that your tool could be fundamental for the adoption of GrandOrgue, so it´s much more important than maybe what you think! Looking forward to collaborating on the expansion of this tool. We could integrate it into the openpipes.org toolset, or I could reference it after established.

[eturpault]

Thanks for your encouragements. I am more motivated than before to achieve this HW to GO automatic conversion, even if it is a hard work !
I think that I will need still some months to have a first working version, then I will need the help of the community to test it on various HW sample sets and make the necessary adjustements, since each editor and sample set has organ description specificities to take into account.

[rnditdev]

Yes, I think we have a good test set in the gamut of samplesets already having both HW and GO versions.
Maybe you and ahal41 could have a unified project, for testing and issue following purposes?

[rnditdev]

I think a good first step is having a fully documented source code of the utilities, so others can build upon them.

[rnditdev]

I was able to understand well both kerkovits´s and your notes, and probably other members of the GO userbase too. maybe it could be better to build the tool in a public project? Not my code, so just suggesting it.

[eturpault]

I prefer to continue to implement it alone, at my speed and my logic, I will release the code in https://github.com/GrandOrgue/ODFEdit as it is with the current published version.

[eturpault]

For your information, I released a new version v2.1 of OdfEdit, see the release note here : https://github.com/GrandOrgue/ODFEdit/releases/tag/v2.1

[kerkovits]

I did not mean that HW Enclosures can be translated to GO Enclosures without significant loss of information (although, I tested the method proposed in my previous post, and sounds acceptable), but I stated that the actual model of HW is quite simple, and the GO developers could achieve the same effect with basic low-pass filters.

[oleg68]

Please post your ideas about Enclosures here #717

[eturpault]

HW can have synthesized, sample-based, or wind-based tremulants. The third cannot be reproduced in GO, but it is fortunately very rare. Sample-based tremulants are stored in the StopRank table, SwitchIDToSwitchToAlternateRank is the switch for the tremulant, and AlternateRankID is the rank storing the tremmed samples. Artificial tremulants are Tremulant objects. StartRate is StartRatePercent, StopRate is StopRatePercent. Period=1000/FrequencyWhenEngagedHz. If FrequencyWhenEngagedHz is missing, its default value seems to be 5 (or close to it). AmpModDepth is stored in wav files for each pipe. In fact, one could multiple the minimum value found in the sample (and multiply it by -100 to get AmpModDepth), but it is very tedious (an average of all pipes should be calculated), so a default reasonable value (e.g., 15) could be written into the ODF, which is still better than nothing. If one does not like it, still can modify it. Note that, for example, the Buckeburg has both types of tremulants, but GO supports only one kind at a same time, so the user should be able to choose while importing, if both types are present.

Hi @kerkovits, I have implemented the sample-based tremulants convertion to GO ODF by managing the alternate ranks and their controlling switch, it will be available in the next OdfEdit v2.4 version. About the artificial tremulants, I don't find in the HW ODF how the 'Tremulant'objects are linked to ranks or stop ranks or samples... Tremulant objects are linked to TremulantWaveform objects which are linked to Sample objects. Each Pipe_SoundEngine01 object has some tremulant related attributes. But I don't see how to link the activation state of a Tremulant object to pipes or ranks objects, have you understood how it works ?

[kerkovits]

The links are provided in the table TremulantWaveformPipe.
I suppose that you misidentified its fields in /src/resources/HwObjectsAttributesDict.txt
My observation is rather:

"TremulantWaveformPipe":
 {
 "IDattr":"",
 "a":"PipeID",
 "b":"TremulantWaveformID", 
 "c":"AmplitudeModDepthAdjustDecibels",
 "d":"PitchModDepthAdjustPercent",
 "e":"HarmonicShapingFilterModDepthAdjustDecibelsAtThirdHarmonic"
 },

"PipeID" refers to Pipe_SoundEngine01 objects and "TremulantWaveformID" refers to TremulantWaveform ones. This is an n to m relation (a pipe can be in many tremulants at the same time, one tremulant waveform may act on multiple times). Attributes "c" to "e" can slightly modify the effect of the low-frequency oscillator. They have no equivalent in GO.

[eturpault]

You are right, my model of the TremulantWaveformPipe object was very incomplete, the one that you propose is the good one. Now I can make a link between the Tremulant and Pipe objects, I am unblocked, thank you !

[oleg68]

@rousseldenis

Setting any temperament (other than original) results in retuning whole organ to a1=440 Hz, so e.g. for Erfurt Büßleben it results in retuning whole organ by 3 semitones.

This is no more an issue since #1366.

Specifying PitchCorrection in the ODF at the organ level allows to specify any other pitch for non original temperaments.

[eturpault]

New release v2.2 of OdfEdit available here : https://github.com/GrandOrgue/ODFEdit/releases

[eturpault]

New release v2.3 of OdfEdit available here : https://github.com/GrandOrgue/ODFEdit/releases.

[kerkovits]

Thank you. The feature 'new buttons to add, link to parents/children or rename an object' seems very promising, although I have not tried it yet.

Is there any progress on importing synthesized or sample-based HW tremulants?

[eturpault]

This is in my "to do" list, but not yet started.

[oleg68]

Happy Easter!

@eturpault , thank you for the new version 2.3. Now I'm able to make the Erfurt organ playable. I added Front and Rear channels to their stops and it works. Great!

Then I tried to add more Windchests Distant and Rear and to move all ranks from existing windchests ranks there. It is not so easy as I wanted. Some notes:

1. At first, desellecting in the Parents window is not so intuitive. I found it after lots of other attempts to do it.
2. The main issue: after changing a windchest of one rank, the old windchest is shut. For moving other ranks I have to remember, what windchest I moved the last rank from and to clik on it for opening. Leaving the old parent open would be high desirable.
3. For moving lots of chld oblects between parents, it would be nice to have a capability to select several ranks in the same time and drag-and-drop them to a new parent with mouse. Is it possible to implement?
4. The Delete button for parents deletes the whole parent instead of detaching this object from the parent. This behavior is not obvious and is quite dangerous. I think it would be better to disable the Delete button for parents at all.

Another useful features to have:

1. Capability of chouse the encoding among ISO-8859-1 and UTF8 for save, including capability to changing for existing ODF.
2. Renumbering the stops and other objects in the manual. Because the three digits of a global stop number usually are the first digit is the manual and two other digits are the number in the manual, the global stop numbers should be changed also. The mouse drag-and-drop interface would be intuitive.
3. Saving the settings across restatts, including the directory where the last ODF was open.
4. And, of cause, the capability of extension the compass would be very interesting (ex. from 56 keys to 61). Don't forget to add Pipe999Tuning and Pipe999Gain in this case.
5. Supporting sample-based tremulants. It is not so difficult in GrandOrgue. I'd add the IsTremulant key for the rank level, but @larspalo would object to this.

[eturpault]

@oleg68 : let's continue the discussion in this post GrandOrgue/OdfEdit#18 (comment)

[eturpault]

Today I released OdfEdit v2.4, with several improvements and new features : https://github.com/GrandOrgue/ODFEdit/releases
Feedback, suggestions and bugs report are welcome here : GrandOrgue/OdfEdit#23

[rnditdev]

I have a possible feature: Extend ranks, taking the last pipe definition, and create new ones in increments of 100 in pitch. Useful to bring 56 keys manuals to 61, the most common key number in MIDI controllers. Thanks.