Hello, Bob Archer wrote: (...) > It's not uninterpreted text, it's text with a meaning. We already have > the Q field which provides a computer readable indication of the > speed usable by player programs. We now have this field to provide > a textual description for display programs. (...) > A player program might default to looking at the Q field to get its > tempo, or it could have the tempo specified on the command line, > or it could have a separate "tempo definitions" file (similar to a > stress file) and attempt to interpret the text in the q field (thus > allowing for tempo descriptions such as "A little too fast") > > A display program can choose to display the Q field, the q field, > both or neither depending on what program specific options are set. (...)
Just to say, yes I like this. I try to repat it in my own words to see if I got it right: The Q:field defines the playback tempo in ways of numeral definition, unchanged. a new q:field can be used to support `a textual description of the speed of the tune' both fields can be used in the header and the body of a tune. Which of them is displayed and/or used for playback is decided depending on what program specific options are set by the user. the `textual description of the speed of the tune' supported in the q:field can be used by program specific options (whether they are predefined :-( or definable :-) ) or together with a `"tempo definitions" file (similar to a stress file)'. *or* by other mechanisms of tempo definitions, in file headers or tune headers which have not been agreed on so far. Advantages of this proposal if I got it right, are: * 100% backwards compatability in tune files, * textual tempo indicators are allowed without the need to agree on if and how they are interpreted by player programs, which I do belive is a separate topic. Simon -- Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
