>One thing about macroes, however, is that you don't _have_ to use them; >you can fully expand the macro in the source if you want to for some reason. >Your proposal doesn't fit that need, because if I _want_ to write >fff (for fortissimo) in the tune, I can't distinguish it from three f >notes unless >I have some delimiters.
If you just want it displayed as text you can use a text annotation "^fff", but if you want it to play as well you have to write some code to recognise it for what it is and do the right thing, so this is not something that can be done with a macro. >In other words, I think we do need to separate out the use of the macro >(which in >my opinion should be a literal text substitution) from the issue of the >syntax of >special symbols and/or flow control. Yes, I agree, but there seems to be endless confusion over what is a macro and what is not. >However, it seems to me that there is no compelling reason to use a >different delimiter >like >!, since it is easy to parse the contents of quoted strings to find out if >they are one of >a >set of reserved words. Any package that doesn't do that will end up >treating them like >they >treat "guitar chords". > >so instead of >U:J = fermata >use >U:J = "fermata" > >(not sure if I've helped here...) I think you're falling into the same hole as everybody else, and thinking of the U: field as a macro definition. In BarFly, the definition U:J = fermata will work OK because the program knows what a fermata is, and will display or play one on any note preceded by the letter J. U:J = "fermata" won't work because the program does not recognise "fermata" in quotes. You don't need the quotes in a symbol definition, and you never write "fermata" in the music - you write J (or whatever letter you have defined to represent it). Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
