Looping HW Conversion

[ahall41]

I downloaded the demos from Coral Pipes recently. The Washington set converts OK but both the Bethesda and Clarendon sets seem to loop on reading the XML. I assume Coral are using some hitherto unused feature of HW.

I gave up and went back to my own scripts this time (no looping detected). Such a lot of work, trying to remember (a) how it worked and (b) how the XML is put together (certainly different to the other's I've looked at).

You might like to take a look at these when you have time? Not a problem for me as I now have working ODFs.

[ahall41]

I'll also be posting a question on the GO Discussions ...

[eturpault]

Indeed there is a bug in OdfEdit, with these sample sets an undefined variable is used when converting switches, which is causing an execution halt in the program. I am going to fix this issue (I have to remember how it is implemented..).
Thanks for the report, I was not familiar with Coral Pipes sample sets.

[eturpault]

The three sample sets of Coral Pipes were interresting to test with OdfEdit, and have permitted to take into use cases and to fix issues not observed with other sample sets (around tremulants and divisions). The changes will be present in OdfEdit v2.20.
In these sample sets the horizontal position of some keys of the manuals are wrong in the HW ODF (too much space between keys), but OdfEdit cannot do anything against that.

[ahall41]

In these sample sets the horizontal position of some keys of the manuals are wrong in the HW ODF

I gave up on these and created my own keyboards panel (using standard components). I think there is a deficiency in how GO handles the keys by using offsets, whereas (I recall) HW uses absolute positioning?

[eturpault]

Yes HW is using absolute positioning. Having the same concept in GO would simplify a lot the conversion from HW to GO.
Having to use Width, Offset and YOffset attributes in GO is more tricky than simply X and Y attributes in HW.

In fact, the issue that I was observing with wrong keys position in GO is not coming from wrong definitions in the HW ODF, it is coming from OdfEdit which was not managing the use case where the X position of the key N is lower than the X position of the key N+1 or even N+2, which is occuring in the sample sets of Coral Pipes only (as far as I know), for the first and last octaves of the keyboards due to the visual perspective effect.
For example for the Great manual of the Clarendon sample set, the ascending order of the first 10 keys at their X position perspective is the following :
key1, key3, key2, key5, key6, key4, key8, key7, key10, key9

If have fixed this for OdfEdit v2.20, now the keys of the Coral Pipes sample sets are displayed correctly in GO. The fix has not been easy to find, using Width and Offset attributes instead of simply a X attribute.