Hello, Anselm Lingnau wrote: > I define `ad-hoc stuff' to be syntax that is used in one particular > header field, such as `if there is a `-' after the metronome speed in a > `Q:' field that means that the metronome speed is not supposed to be > printed'. Why don't we allow a `-' after a composer name in the `C:' > field so the composer name will not be printed? There are plenty of > cases where one would want to have this facility -- for example, if you > typeset Bach's Well-Tempered Piano you don't need to put `Johann > Sebastian Bach' across the top of every prelude and fugue since the > information is already on the title page of the book. Allowing such > things in one place but not in another is one aspect of what I call > `ad-hoc' syntax.
Why not. I know you are convinced that it is important that abc does *not* allow this to be decided by the transcriber. But for me: why not. > Again: My point is that the ABC representation of a tune should not say > what must be printed and what mustn't, since it is impossible to foresee > in what context the ABC is going to be used. The ABC representation of a > tune should give as much musical information as is reasonable but should > not specify how programs will make use of it. in certain cases it will have to allow exactly this in the future: For example by forcing display programs to display all copyright related information, usually the C: field and in case of traditional sources supported by an archive all informations the archive asks for to allow reproduction (that acctual programs do not do so is a big problem in the moment for me and a reason not to add any more tunes on internet). > It should not be necessary > to change the ABC representation of a tune just because it is supposed > to be played back at a different speed this afternoon again, no sarcasm please, You know that the above was not part of any of my examples. The idea was to allow the transcriber to add a program readable speed besides a composer chosen textual tempo indicator, to make sure the playback does not fall to an incorrect default. > Finally, let's for the moment stipulate that your proposal goes through > and that we will be able to write > > Q:1/4=60 - Andante ma non troppo > > If you define that everything from `Andante' to the end of the line -- > excepting a `%' comment, of course -- is a textual tempo specification > then how are you ever going to put in another data field if that should > become useful at some point in the future? So on an ad hoc basis :o) : Q:1/4=60 - Andante ma non troppo SEPARATOR whatever you want since the separator got out of use with the introduction of the "minus" but better ask those who opposed to the SEPARATOR idea about their oppinion abot the keyword=value proposal (as the keyword is in a way a kind of separator). > > > [Musical content vs. presentation issues] > > As pointed out this your argument does not stop the need of a stringent > > syntax for this, since it does not much make a difference which part of > > a program has to recognize a string. > > The idea is to keep musical stuff apart from presentation stuff. > Presentation details might go into a separate file, using syntax (like > CSS, if you will) that is more appropriate for the purpose than > bastardized ABC. In my opinion it is a very bad idea to mix musical and > typographic information like your `Q:1/4=60 -' proposal does -- even a I dont know if you got it: if a string of abc text should be readable for a display only program it must follow the same kind of syntax as if the abc program itself (whatever this is) should interprete this obligatory. > %%abctypesetter dont-display-metronome-speeds abctypesetter will fail if the abc syntax is not computerreadable. So If the Q:syntax says we wont care about display as a priciple, the %%abctypesetter commands may fail. > > and if features are not implemented, it may also cause people to include > > %%programspecific commands whithin files. > > Does that mean we need to put everything that could possibly occur > somewhere in some kind of musical notation into ABC, just so people > don't feel tempted to use `%%something'? In a way yes, not about "everything that could possibly occur" but "everything thats possible" . This would help to persist file exchangability. > support or not. (And if you are in the business of sharing musical > *presentation* -- like near-facsimiles of old musical scores: If ABC > works for you in this context then more power to you, but people will > like you better if you put up your formatted score as a PDF file > alongside a very I *know* whats my business. My problem is that I would like to use abc formating for distributing music (filesize, exchangeability, playability & displayability, its freeware) but in this case there are some things that tangent the display. > I keep going back to HTML but it really seems to me that we're about to > make all the mistakes over again that the HTML crowd made a few years > ago. in your statements, please keep in your mind that I do not understand a word about HTML, maybe other listmembers too. Simon -- Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
