Simon Wascher <[EMAIL PROTECTED]> writes: > It is not trivial to > tell where music ends and side information beginns. And as a transcriber > of historical sources it is often very important to cover some "side" > information within the exchangeable file, not just in the printed output > (for file exchange). This "non musical" information does influence the > musicans output and therefore is in a way part of the music. > Abc formatting would be worthless to transcribers if it is limited to > pure audible phaenonenons.
Nobody says that ABC should be limited to `pure audible phenomena'. We do have repeat signs and so on which are not audible (at least not in a direct sense). However we should not try to define the meaning of the ABC notation in terms of playback and notation programs, but in terms of the musical ideas which are being transported. Saying in the standard that various bits of such-and-such a field must be displayed in such-and-such a way is a bad idea -- it is much better to say that the field *means* this-and-so in musical terms and leave it to the software authors to figure out what to do with that piece of information. This means that the information is all there in the file for anybody to look at it, but that the authors of ABC processing software have maximum flexibility to make use of it (or not). There is absolutely no need to clutter up an ABC tune with special notation that says whether `1/4=120' must be printed with a little quarter note or `1/4' or not at all, or to the top left or bottom right of the music or whatever, when it is a lot easier to put options like `PrintMetronomeMarking: true' in an ABC notation program's format file, or `--print-metronome-marking' on the command line, or a check box in an interactive dialog or whatever. As far as your `side information' is concerned that should only show up in the exchangeable file, not in the printed output: The ABC does provide the notion of `comments', i.e., lines that start with a `%'. > I understand that you are not interested in these aspects of music > notation, and I can tell you that I am working hard that you will never > come accross those features you do not need, simply do not use them and > never read the readme file description on those features. I am very much > concerned that simple abc remains simple but in the same time please > accept that other people do expand features you never heard of and never > will use. Please don't second-guess me. I'm quite interested in seeing the ABC standard develop and improve, thank you very much. However we should try and avoid the mistakes that others have made, such as deliberately mixing presentation and content, and we should try to keep the notation as simple as possible. This is why I am in favour of Jack's proposal for tempo macros, and also why I like Phil Taylor's macro mechanism for decorations much more than the idea of inventing two hundred little special symbols within the ABC language just so the urtext of Bach's inventions can be represented in ABC. I am not prepared to accept the idea that the ABC language needs to be cluttered up, say, with magical end-of-line comments that have special meanings in some header fields just so something can be expressed which nobody really actually needs to begin with. Anselm To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
