I. Oppenheim writes: | | As such programs may happily ignore all this, | though the resulting output won't be optimal/ | as intended by the transcriber.
A good point to mention occasionally. One of the very real dangers of such a standard is that it could be quite daunting to a programmer contemplating writing some abc software. We should perhaps be mentioning that we don't expect all programs to implement everything, especially not in their first version. The programmers should just be somewhat aware of the things they don't implement, so a program will do something reasonable (usually warning messages) when it finds something that it can't handle. This will happen anyway. Programmers will implement what handles the music they are dealing with, and face the rest as problems appear. This is how good software is developed, and we should encourage it. There are a lot of good uses for limited tools that solve a narrow problem well. But this implies that we will always need lists of which abc software implements which parts of the standard. If we do this, we can make it easier for users to find the software that handles their musical needs. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
