completely. These are people who record large collections of tunes (admittedly,
each tune is likely to be a 'simple folk melody' with or without lyrics),
often in the hundreds or thousands of tunes, related by genre or origin.
They will use abc instead of or in addition to tunebooks. These people collect tunes
and transcribe them, exchange them via email, publish them as a resource
on the internet or as a collection on CD-ROM and also want to print them as
dots or play them when required. They need software to proofread or proofhear
what they've entered, to index, to search, to compare tunes, etc. Sophisticated
typesetting is not likely to be a first-order requirement, certainly not at the
expense of readability.
Arent Storm wrote:
agreedHaving read the discussion about bang & co for quite a while I' d like to add my two (euro)cents. I have more or less implemented a full abc import/export of ABC in MusiCAD based on 1.6 and beyond, trying to accommodate as much extensions as possible (words/multivoice/etc).
When implementing linebreaks the CR/LF, I took the approach of
ignoring CR/LF at all. MusiCAD determines clustering, barlines, linebreaks
pagebreaks and so on, so the information abc provides in this respect
was simply ignored without much consequenses.
I guess the same will hold for other notation software using abc as second
language.
As far I can see there are two main visions within the abc-communityreplace 'sight reading' by 'exchange, archival and reference format' and rethink your statement
1) People using ABC for sight reading, in fact not in need of any software whatsoever.
other header info is remarkably importantWhen you are using abc this way (where it has its roots) the need for ! as forced line-break is obviously very low. I guess that a lot of other header info will not be used either. Music thus written has to be as concise and clear formatted as possible; linebreak equals CR/LF is a perfect solution for that job.
Not the majority if you weight the users by the amount of published material,All bells&whistles like multiple staves, fancy !trill! symbols in-line words and so on will also disturb the ease of human reading that was the power of abc. A line continuation is more or less nessecary because the paper (screen) that they're writing on is also limited. For group1 the upcoming standard will be more or less ignorable... as long as ABC2.0 compliant software will read/play/display their abc's albeit with linebreaks at different places
2)
People who use abc mainly as a language to engrave music
(the majority?) might look at it differently.
I suspect.
agreedAs soon as abc is fed into software to engrave it on paper, the layout *CANNOT* be assumed to fit on paper (which size paper/screen should it fit on?) Software will of course take care of linebreaks (and should do the same for barlines...) When using abc this way a forced-linebreak-device other than CR/LF is simply nessecary and the layout should not be cluttered by CR/LF linebreaks. Luckily notation software can easily be instructed to ignore CR/LF and place linebreaks where nessecary for the job based on layout instructions in the program itself or meta-comments in the file itself like
%%FMT-BarsPerLine 4
%%FMT-LinesPerPage 11
%%FMT-TitleFont Roman 11 bold
(all instructions not meant for goup1) ;-)
Thus the original abc remains unbroken, and musically intact, be it that the beforementioned layout will be different than perhaps
intended by the author, which seems a minor issue.
agreedI am afraid that you cannot have everything of both worlds simple abc as in thge average reel or a multi-voice symphony In fact the current standard tries to describe the layout of a tune using CR/LF which is IMO undesirable; it should describe the music only not the way it must fit on paper.
Arent
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
wil To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
