Jack Campin <[EMAIL PROTECTED]> wrote: > >In an attempt to wrap up this thread, would the following proposal > >for a new field meet everyone's requirements ? > > > >Field Name: q:playing style > >Header: Yes > >Tune Body: No > >Description: Contains a written non-numerical description of the > > tune's tempo or "mood". > > > >Examples: > > > >q:Allegro > >q:Lento > > That says exactly nothing about the semantics.
I think it does say something about the semantics. The text is part of the 'q' field which gives it the semantics 'a textual description of the speed of the tune'. > Unless your "q:" field provides me with a way of DEFINING those > strings in a musically intuitive way so that a numerical playback > speed can be statically deduced from the musical text (e.g. by a > playback program), there is no point in what you're suggesting. There > are already about 10 different ways to put uninterpreted text into a > tune header, we *do not* need another one. 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. > And these *have* to go in tune bodies. It is quite routine for tempo > to change in the middle of a piece. Agreed. I'd suggest that Q and q fields be allowed in the body of a tune. > That suggestion ignores 95% of the issues we've discussed in this > thread so it's nowhere near "wrapping it up". The central problem is > how to specify the required definition mechanism. Actually, I think the advantage of the suggestion is that it ignores 95% of the issues discussed. I think it cuts to the chase. 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. With the caveat that q should be allowed in the tune body I like the suggestion. I think it hits the sweet spot between power and simplicity, and it avoids adding fields which should be placed before the beginning of the first tune in a file. The extra 'per file definition fields' seems like quite a major extension to ABC to me, I don't think we have anything quite like that at the moment, and I'm not convinced about the need to add it for this. > In the case of pipe band marches, each band today has its own set of > tempi. There are ABC files out there with hundreds of marches. It's > up to the pipe-major to decide the speed, NOT the tune transcriber, > and it's a waste of the P-M's time if they have to go through the > whole file and treat every tune as a special case. I would suspect that the P-M would have a tempo definition file on their computer containing their preferred definitions and would have set the playback program to use the q field rather than the Q field. Bob ---------------------------------------------------------- -- Bob Archer [EMAIL PROTECTED] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
