v2.4

[eturpault]

30 May 2023
Changes compared to v2.3 :

• added a menu item checkbox to select the file format to use when saving an ODF (ISO_8859_1 or UTF-8 BOM)
• added a menu item checkbox to disable the automatic objects tree expand on object selection
• added a menu item checkbox to enable the wave based tremulants convertion from HW to GO
• added a menu item checkbox to enable the unused ranks convertion from HW to GO
• ctrl+s keys permits to save changes in the edited object and to save changed data in the ODF
• configuration data of the application (last ODF folder, options of the menu) are saved in a file OdfEdit.cfg
• added the possiblity to search a text inside the loaded HW ODF
• improvements made in the objects list/tree behavior on object selection or change
• objects having child(ren) cannot be deleted with the button Delete
• the parents/children of the selected object can be selected and edited in the central list (above the text editor)
• a double-click on a parent/child object makes it the selected object in the list/tree
• escape key permits to close the pop-up windows permitting to select parent/children objects
• HW2GO : removed the attribute AcceptRetuning=N in ranks of pipes
• HW2GO : pitch tuning attribute used for pipes which the sample has a different native frequency
• HW2GO : convert the conditional switches (switches which the state depends on the state of other switches)
• HW2GO : convert the synthetized and wave based tremulants
• HW2GO : the stop and coupler objects are numeroted according to the manual number to which they belong to
• several bugs fixing as at each release

Coming evolutions in next release :

• manage drap-and-drop action on an object in the lists/tree to move it under another parent object
• add a manual compass extension feature
• suggestions of users are welcome

---

This discussion was created from the release v2.4.

[kerkovits]

I tried it, and got playable results. Good work!
In the following sample set:
https://www.sonusparadisi.cz/en/downloadable/download/sample/sample_id/15/
I encountered a problem: The clickable area turned out to be larger than the image for some GUI elements. It seems that ODFEdit is confused when ImageSet→ImageWidthPixels and ImageHeightPixels is missing. A possible solution would be to check the exact size of the bitmap and clamp ImageSet→ClickableAreaBottomRelativeYPosPixels and ClickableAreaRightRelativeXPosPixels to it. However, it would slow down conversion, as you need to load a raster processing module to Python, and check every bitmap for which the size is not specified in the ODF.

[eturpault]

With this sample set using the exact size of the bitmap would not help to define precisely the mouse clickable area, since it is larger than the button clickable area. For example with the stop "Flauta 8" of the manual I in the Single Jamb panel, here is the bitmap :

Having ImageSet→ImageWidthPixels and ImageHeightPixels not defined in the HW ODF is not a problem for OdfEdit, however there is a bug in the calculation of the clickable area width and height that I just realized thanks to this sample set.
I calculate :
MouseRectWidth = ClickableAreaRightRelativeXPosPixels
instead of
MouseRectWidth = ClickableAreaRightRelativeXPosPixels - ClickableAreaLeftRelativeXPosPixels
and the same for the height.
I just made the fix, so now the clickable area width and heigh are actually the one defined in the HW ODF, but it is not enough, the clickable area is still larger than the button area, especially on the right and bottom sides. This is because it is defined like that in the HW ODF which has :

ClickableAreaLeftRelativeXPosPixels=70
ClickableAreaRightRelativeXPosPixels=476
ClickableAreaTopRelativeYPosPixels=35
ClickableAreaBottomRelativeYPosPixels=245

looking at the bitmap with an image editor, the attributes should be rather :

ClickableAreaLeftRelativeXPosPixels=73
ClickableAreaRightRelativeXPosPixels=409
ClickableAreaTopRelativeYPosPixels=39
ClickableAreaBottomRelativeYPosPixels=224

If I set manually the values below in the GO ODF the clickable area in GO is good :

MouseRectLeft=73
MouseRectTop=39
MouseRectWidth=336
MouseRectHeight=185

So except the fix that I did in OdfEdit, I don't see what I can do more, there are wrong coordinates in the HW ODF which have to be fixed manually in the GO ODF. What do you think ?

Besides, in OdfEdit v2.4 I already read the image size in the bitmap files if the attributes ImageWidthPixels and ImageHeightPixels are not defined in the HW ODF. This is due to the fact that some sample sets don't define the panel width and heigth, I suppose that Hauptwerk adapts automatically the panel size to the position and dimensions of the images which are inside the panel. So I need to know the images dimensions to set in the GO ODF the panel size when it is not defined in the HW ODF.

[kerkovits]

In my opinion, ODFEdit should check whether the clickable area fits into the image size. I see two options, which are not mutually exclusive:

1. During Check ODF validity, raise an error if MouseRect is too large. Now ODFEdit checks the resulting file with no error message.
2. On HW2GO, check the real image size, and if the lower or right border is not within the image, change its value to the maximum permitted value.

[eturpault]

Look at the images in the folder OrganInstallationPackages\001810\registry_simple_jamb of the sample set (from which is extracted the image that I inserted in my previous comment), you will see that in this case the clickable area has to be smaller than the image size, not equal to the image size.
With the fix that I did yesterday for OdfEdit v2.5 the GO ODF will contain exactly what is defined in the HW ODF, which I expect is coherent with the images size. I could add the check to ensure that the MouseRect is not larger than the image size, but in the case of this sample set it will not be sufficient, the MouseRect has to be smaller than the image size in both width and height, and for this OdfEdit cannot analyze the content of each image to detect the real coordinates of the button inside the bitmap.

[kerkovits]

You misunderstood me. If ClickableAreaRightRelativeXPosPixels or ClickableAreaBottomRelativeYPosPixels is larger than image dimensions, decrease them to image dimensions, and calculate MouseRect with these modified dimensions (keeping ClickableAreaLeftRelativeXPosPixels and ClickableAreaTopRelativeYPosPixels intact). In this way, all errors are eliminated.

[eturpault]

Indeed we are speaking about different topics, sorry. ClickableAreaRightRelativeXPosPixels or ClickableAreaBottomRelativeYPosPixels larger than image dimensions should not occur if the HW ODF is well designed, and probably Hautpwerk would reject such an ODF as GrandOrgue does for the same kind of issue. Since we convert to GO format HW ODF which are running well with Hauptwerk, I suppose that they are correctly designed and without errors.
Anyway I can add in OdfEdit the test that you suggest in order to ensure to have MouseRect dimensions not exceeding image dimensions for the buttons.

[larspalo]

The 2.4 version was kind of successful in converting the St. Carlo, Brescia organ from Sonus Paradisi. Kind of, because the original version output couldn't be loaded in GO due to a mis-calculation of the number of (referenced) bass pipes to the short octave (24 pipes available but start reference from number 5 without decreasing the number of pipes accordingly). The modern version could load and play but lack the necessary pitch tuning lines to fill out the gaps in the last octave (short octave original with stretched out samples that should form extrapolated pipes not present in the original). There are a few other instances where pitch tuning lines are necessary too. Also, there seems to be no keyboard noises present in the conversion, though they do exist in the sample set (they do exist in the .xml file).

But overall, it's a nice improvement over previous versions that totally failed the conversion! Also, the way the stop noises are handled deserves some extra credit! I'll take note of it and utilize the same (or at least a similar) method in the future.

[eturpault]

To have right now the unused noise ranks converted to GO ODF when the option is enabled, simply comment the lines #6584 and 6586 in OdfEdit.py v2.4.

[kerkovits]

Thank you, it works.

[eturpault]

@kerkovits : I implemented the keys noise conversion from HW to GO, you can test it by recovering the file OdfEdit.py in the branch v2.7beta.

[kerkovits]

I tested it, and it works.

[eturpault]

Fine, thanks for the feedback !

[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.

[eturpault]

Thanks for the proposal. This new feature is planned for a next release as indicated at the end of the release note of the v2.4 : "add a manual compass extension feature".
What I intend to implement is to ask the user to select the Manual(s) to extend and until which MIDI note number to make this extension (under or above the current compass).

In order to preserve the original tuning of organs which have unequal temperaments, I think that it is better to make the extension by retuning pipes by one octave (so to use PitchTuning=1200) instead of by less than octave (PitchTuning=100 for example), has someone a opinion on this ?

[oleg68]

I think that it is better to make the extension by retuning pipes by one octave (so to use PitchTuning=1200) instead of by less than octave (PitchTuning=100 for example), has someone a opinion on this ?

I agree totally.

[25Tim]

ODFEdit.exe (V2.4) make Path Image=..\OrganInstallationPackages.... and other, this don`t work in GrandOrgue. You can make the correct Path in ODFEdit (Image=OrganInstallationPackages....)?

[eturpault]

Which error do you get in GrandOrgue to say that "this don't work" ? Which OS are you using ?
You are the first one to report such an issue.
As indicated in the help of GO : "File paths are relative to the location of the ODF." The ODF being located in the folder OrganDefinitions of the Hauptwerk sample set, the relative path to access the folder OrganInstallationPackages which is at the same directory level is actually ..\OrganInstallationPackages, and it works well.

[25Tim]

[eturpault]

Please share here in a file all the logs generated by OdfEdit when converting the HW ODF to GO ODF and by GO when loading your ODF. Since OdfEdit v2.0 the files path have been always generated in the same way and loaded without issue until your report.
Have you unzipped all the files of the sample set archive ?

[25Tim]

[eturpault]

I don't see the pictures, but what you describe to solve your issue leads to think that your ODF is located in the folder where are the OrganDefinitions and OrganInstallationPackages folders, and not inside the OrganDefinitions folder as OdfEdit places it.