Simon Wascher <[EMAIL PROTECTED]> writes: > there are several reasons for this, most important to me is the > transcribers request that information given in the source is passed on > in the abc file.
I don't see the problem there. You put in your `Q:' header whatever the original source said. If you want metronome markings as well as a verbose tempo specification then say Q:Allegro 1/4=120 Q:Allegro "Pretty quickly" and use a notation program that will let you propagate the actual numerical definition of a macro like `Allegro' into the typeset output, so you get something along the lines of Allegro (Pretty quickly) - .|=120 This is purely a presentation issue and does not pertain to the actual ABC standard, which should describe the contents of ABC files. > included in the topic is the separated proposal to allow program active > textual tempo markers by the use of macros, maybe we can excluse this > from the actual discussion since it seems to be quite common sense and > does not directly touch the playback/display problem. I disagree. This is where the discussion started, and I think Jack's proposal is eminently sensible. A `solution' that ignores this original issue is not a solution at all. > the core problem is the impossibility of playback only (B) in the actual > standard. Playback-only tempo is something that you set in a player program, no? > the second the impossibility to have display only (C) in a way that the > text in question is identified as tempo indication (relys on B) too !) A tempo indication, by current definition, is whatever is in the `Q:' field. Whether this is for display or playback or both depends on what the programs that look at the ABC make of it. > the third the desire to have both in one (D), and this in a intuitive > clear syntax. That is exactly what I have suggested. > There is no way passing the fact that displayed and playback tempo > indicaters are two totally different (but related) topics that both > should be covered by abc. I don't buy this. A composer comes up with a tune and suggests a speed at which it should be played. This is what he puts on his manuscript. So where do you (the transcriber) come in to say `no, what it says there is wrong, this piece must be played at 2/3 the speed and the ABC file that I will give out to everybody must say so'. This will only serve to confuse people who listen to the ABC file as played at `playback tempo' by an ABC player while looking at the sheet music as output by an ABC notation program giving the `display tempo'. There is nothing wrong with having a tempo associated with a metronome number using Jack's proposal as well as an explanatory note in the manner that I suggested. What I think is unnecessary is having two conflicting metronome numbers within the same ABC tune. This is something which is much better handled using Jack's macros and/or a player program that will let you override the actual speed from outside of the ABC-notated tune to be played. > Leaving the display matters to the display programs alone as you sugest > sounds intriguing and covers B) but failes to handle C) and D). > The "q:" solution (extra field for displayed tempo indicaters) covers > the identification of "display only tempo indicaters" (C) and with the > support of an "not display Q: option" in the displaying programs that > you sugested all possibilities could be handled. The SEPARATOR in this > solution is a "d:" field plus an optional feature in the displaying > programs. > I do not like this solution much since it relies on program options > which are not part of the standards syntax and its very likely that this > causes misunderstandings by users, but for my purposes this would work > if its covered by abc2ps. This is a mess. I don't like the idea of specifying in the ABC standard what programs should do with the information in an ABC tune. The ABC standard should explain what the various bits and pieces in the notation *mean* -- in musical terms -- but not how programs should make use of that information. For example, IMHO it is OK to say The `Q:' field indicates the speed of the subsequent material, either by a metronome reference such as `1/4=120' or by a reference to a previously defined macro such as `Allegro'. (of course this is not detailed enough to be an actual specification) but not The `Q:' field indicates the speed of the subsequent material, and its contents should be printed at the top left of the first staff, with a note of the appropriate value to the left of the equals sign and the numerical tempo specification to the right. These details should be left to notation programs in the same vein that ABC right now doesn't specify, e.g., the widths of the margins, the font and size of the tune title and so on. Similarly, player programs should use the contents of the `Q:' field as a default speed but allow the user to override this in the same manner that notation programs allow the user to override the default type size for the tune title. The tempo macros suggested by Jack Campin make it possible for users to specify their own default tempos that differ from the ones in the ABC tunes, and also player programs could allow the user to either set an absolute tempo for everything or say that everything should be played at a given fraction of the notated speed. (Really good player programs could make this conditional, e.g., play everything at half speed if it is originally faster than 1/4=120, else leave it alone.) In my opinion, the standardized ABC notation should try to stay away from the issue of music *formatting* (as opposed to representing musical content) as far as possible. This currently works reasonably well (ABC does specify line breaks but this is really an accident of history). I would hate to see the ABC notation go down the same road that, e.g, HTML did, by mixing presentation with musical content to a degree that made the two inseparable. > I would prefer a syntax that recognises whether Q: field info is for > display and playback or just for playback. If so, I belive the just for > display information *could* also be recongnised and be included here. If > not it can be put into a "q:" field. > > > Q:Allegro "Pretty quick" > > C:[Traditional] > > I would prefer not to use quotes as Separators as they are very common > characters and cant see why they are better than square brackrets. The problem of quotes inside quoted material is easily solved by putting \", wich is TeX-like as well as used in many programming languages such as C. Also, quotes are already being used in ABC notation in other contexts like `V:' lines, where at least abc2ps (and relatives) currently allows stuff like V:Eh clef=treble name="English Horn" sname="Eh." It would be less than sensible to define different quoting standards depending on which header field is under consideration, so there is something to be said for quotes already. In any case, maybe we should go for something like Q:Allegro comment="Pretty quick" just to make the `keyword=value' option notation consistent? This would also make the extra tempo information perfectly obvious (at the expense of some typing) and allow further expansion by other keywords in the future. > > under the stipulation that a tune would not have a `display speed' > > of 1/4=90 and a `playback speed' of 1/4=120, > > Its likely that exactly this is desired: One metronome number comes with > the source and another is used for actuall playback. Can you tell me a situation where it would be mandatory to play a tune at a predefined speed that is wildly different from that given in the source? I would prefer to be able to override the speed from within the player program (via an interactive control and/or a command line option), e.g., to slow down a piece when I'm practising playing along with it, without having to change the ABC input. (This is actually one of my pet peeves with abc2midi -- that it doesn't have a command line option that overrides `Q:'. Right now I need to change the ABC input all the time.) Anselm -- Anselm Lingnau .......................................... [EMAIL PROTECTED] Now let me explain why this makes intuitive sense. -- Prof. Larry Wasserman To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
