At 23:47 2001/11/27 +0000, Jack Campin wrote: >:> So, *how* does it describe the speed? How does your suggestion >:> distinguish texts that define speeds from arbitrary gibberish? >: It doesn't, at least it doesn't any more than a program can >: distinguish between the actual title of the tune in the title field and >: arbitrary gibberish. I don't see a standard (as in ABC standard) way >: of being able to check this field without severely limiting the text >: that can be put in here > >I suggested a way: "sdbdkjvhfdb" defines a tempo if there's a tempo >definition in the environment, i.e. a line like > > Q:[3/4] sdbdkjvhfdb 1/4=96
It seems as though the principle sticking point here is whether the association of a tempo with an arbitrary text string should go in the ABC file or be separate. I guess that this depends on whether it would make more sense to have tempos defined on a 'per file' or 'per user' basis. >:> Any syntax that works in an external file can work in an ABC tune >:> file. >: I don't think I understand what you're talking about here. Do you >: mean that any external file that any program decides to use should >: be capable of being put into an ABC file? > >I mean that if the external file syntax is sanely designed we can add the >design to the syntax of ABC. As it stands, it seems that externality is >being used as an excuse for using any old rubbish as notation - on the >assumption that only one program will ever use it and hence that only one >programmer needs to care how twisted it is. There are enough historical >precedents now to say how dangerous an attitude that is in the long term. Whilst I agree that would could add sanely designed external file syntax to ABC I'm not sure we'd want to. I can't speak for anyone else, but my reason for wanting to put things into external files is to try and get a good split between things that belong in ABC as part of the representation of the music, and things that are 'presentation options' that can live elsewhere. My preference would be for ABC to be as small as possible, but no smaller. Bob ---------------------------------------------------------- -- Bob Archer [EMAIL PROTECTED] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
