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.