• Welcome to the Pipe Organ Forum! This is a part of the open community Magle International Music Forums focused on pipe organs (also known as "church organs"), organists, organ music and related topics.

    This forum is intended to be a friendly place where technically advanced organists and beginners (or even non-organists) can feel comfortable having discussions and asking questions. We learn by reading and asking questions, and it is hoped that the beginners (or non-organists) will feel free to ask even the simplest questions, and that the more advanced organists will patiently answer these questions. On the other hand, we encourage complex, technical discussions of technique, music, organ-building, etc. The opinions and observations of a diverse group of people from around the world should prove to be interesting and stimulating to all of us.

    As pipe organ discussions can sometimes become lively, it should be pointed out that this is an open forum. Statements made here are the opinion of the poster, and not necessarily that of the forum itself, its administrator, or its moderators.

    In order to post a new topic - or reply to existing ones - you may join and become a member by clicking on Register New User. It's completely free and only requires a working email address (in order to confirm your registration - it will never be given away!). We strive to make this a friendly and informative forum for anyone interested in pipe organs and organ music.

    (Note: If you wish to link to and promote your own website please read this thread first.)

    Many kind regards
    smile.gif

    Frederik Magle
    Administrator

    Krummhorn
    Co-Administrator

Hammond Temperament in GO?

scush

New member
I have changed the setter element back to "general" .
GO then gives all the warnings etc, a second message box is not displayed, as it is in rev 1191.
 

e9925248

New member
General/divisional related warnings should be fixed in trunk.
Additionally some errors are now correctly reported as incorrect config entry.

The line number was off by 1. It should match any program counting lines only by considering the line break in the ODF. I don't know, if word behaves also this way or more like a DTP program.
 

scush

New member
Regarding the cmb file.

After loading barton (133 stops in generals), then saving, only 132 are shown in the cmb file.
This is still the case at rev 1206, although the error is not now shown.
This is not an issue anyway, as when the combinations are set this is resolved.

It is still the case that when a fatal error is found, the log window continues to fill up with unused entries until GO hangs also leaving the log window not responding, the error message box is still not shown.
This occurs on both machines that I use, I guess this does not occur on linux.

PS.
Fatal errors are displayed with the error message box on small organs example, "Burea_Funeral_Chapel"
But not on large ones, "pita" which just hang.

Even the pipes are being logged as unused odf entries.
 
Last edited:

e9925248

New member
After loading barton (133 stops in generals), then saving, only 132 are shown in the cmb file.

Look at the general content: There is one dupplicate entry, which is "fixed" by GO.

It is still the case that when a fatal error is found, the log window continues to fill up with unused entries until GO hangs also leaving the log window not responding, the error message box is still not shown.
This occurs on both machines that I use, I guess this does not occur on linux.

PS.
Fatal errors are displayed with the error message box on small organs example, "Burea_Funeral_Chapel"
But not on large ones, "pita" which just hang.

Even the pipes are being logged as unused odf entries.

In my option, you should get an error message box even for large organs. Maybe the message box is hidden in the background or the mass of log messages just delays the display of it.

I have changed GO to avoid logging unused messages in the case of a fatal error.
 

L.Palo

New member
Hi!

Many of the "unused" lines in the odfs were intentionally present so that if the samleset anyway was loaded into a 0.2 version or imported into HW it would still work to a certain degree (at least with minimal changes).

I'm really questioning the necessity to log every unused/duplicate line. Errors and faults are things that should be logged. As the GO odf spec continually undergo changes this current behaviour can become a bit troublesome. One of the keys to user friendliness is for the software to fail gracefully if at all.

If we still continue to keep and support the "HW1" basis for the odf (out of legacy reasons) I think that no single line that will make it possible to load the set according to that spec should be considered unused even if it's overridden with newer features for the odf reader that can manage to use them. With the later additions we've made on top of that spec I think differently, as logging might have a use to encourage a good and sound construction of the odfs.

As the parsing of the odf seems to be pretty quick, I don't think that allowing overrides will significantly slow down the process in normal use cases.

Kind regards

Lars P
 

e9925248

New member
Many of the "unused" lines in the odfs were intentionally present so that if the samleset anyway was loaded into a 0.2 version or imported into HW it would still work to a certain degree (at least with minimal changes).

This is only relevant for samplesets with samples being 16Bit, 44.1kHz.
With the addition of more sample set formats in GO, it is getting less popular.

I'm really questioning the necessity to log every unused/duplicate line. Errors and faults are things that should be logged.

Duplicate is definitly an error.

Unused is important for people creating/changing ODFs. It hints:
* settings, that in contrast to the option of the ODF creator, are not supported in that context
* incorrect spelled entries, which therefore does not take effect

Barton is a good example for this.

I agree, that they are not relevant for the normal users, therefore they are only logged in a non-blocking, background window.

As the GO odf spec continually undergo changes this current behaviour can become a bit troublesome. One of the keys to user friendliness is for the software to fail gracefully if at all.

I don't intent do break existing organs - they should contine to load. I took extra care, so that every ODF change is backward compatible.
GO should even still continue to load HW1 organs (with a few warnings)

The last changes were only related to the parser: GO started to reject or warn about syntax errors.

The permissive, non-reporting parser yield to people inventing their own ODF syntax "extensions" by using parser bugs. If one ODF using it is published, others start taking it as example.

To inhibit this, I have restricted the parser. All widely used constructs are only reported as warning, while everything else is rejected.
If I put a construct in the wrong category, please report it.

If we still continue to keep and support the "HW1" basis for the odf (out of legacy reasons) I think that no single line that will make it possible to load the set according to that spec should be considered unused even if it's overridden with newer features for the odf reader that can manage to use them. With the later additions we've made on top of that spec I think differently, as logging might have a use to encourage a good and sound construction of the odfs.

I don't want to call HW1 the basis of your ODF, as it would be too restrictive.
It should only be loadable.

As the parsing of the odf seems to be pretty quick, I don't think that allowing overrides will significantly slow down the process in normal use cases.

GO should flag anything not in our ODF reference (or if there is still a GO bug).

It is possible to extend this list (and adapt the parsing accordingly). Please come up with your suggestions.
 

scush

New member
Hi
I now have rev 1212.

In an odf for a 3m+p I found on web, and use most of the time, I found all sorts of invisible bytes.
This loging has achieved much.

I have tried the reverb patch, it's good that all sample per buffer size's can be used.

PS. Sorry it was just 0d 0a 09 etc.
 
Last edited:

scush

New member
Tremulant entries in the section [manual???]
Are unused

Knowing this, makes the "invented" combination entry, not of the same importance
This is confirmed by using GO v1
 
Last edited:

e9925248

New member
Tremulant entries in the section [manual???]
Are unused

Knowing this, makes the "invented" combination entry, not of the same importance

Tremulant999 in the Manual999 sections are used by GO - up to NumberOfTremulants.
 

scush

New member
No I have never seen one
It seems to me as if these entries do about as much as comments=
and we have been fooled by them

Anyway it is illogical, a tremulant is part of a windchest, not a manual.
 
Last edited:

e9925248

New member
No I have never seen one
It seems to me as if these entries do about as much as comments=
and we have been fooled by them

Anyway it is illogical, a tremulant is part of a windchest, not a manual.

There is communication problem between us.

So:
Tremulant999 in Manual999 is valid and should be never flaged as unused by GO.
If you find such a case, please report the bug.

In fact, this setting is used for setting the divisional scope.
 

scush

New member
As I had only tested ODF's that do not store tremulants in divisionals I did not know this
I thought I had found somthing, but now realize I had not.
All I can say is sorry
 
Last edited:
Top