> I think it is reasonable to require |: at the start of a repeat section
Not given the amount of ABC out there that doesn't have one.
Like all of mine.
And I am NOT interested in re-editing the whole damn lot to please
simpleminded fussbudget implementations.
: If we can have multiple alternate endings, why not multiple alternate
: segments within a repeat, not necessarily at the end? This is common
: in pipe music, and we have seen requests for it on this list.
I suggest we hold off on this one and get the simpler extension fixed
first (while bearing in mind that it might be added later and shouldn't
be precluded).
The historical reason why it's so common in pipe music is because of the
format of pipe tune books. For a really big umpty-part tune, you needed
to save space to get it all one page (see David Glen's collections of
about 100 years ago for most of the examples; you can watch his typo-
graphy getting increasingly desperate as he approaches the bottom of
the page). Publishers less concerned about saving paper, as in most
modern tune collections, make much less use of it.
There is probably no point in going for it unless we can do an altogether
more sophisticated structure. A very long time ago (years) I posted an
example of what such a structure might do: the 9/8 march "Heights of
Dargai" has the form ABAC DBDC, and I've seen that in a modern book (in
two staff lines) as
[1,2 A [1,3 B :|
[3,4 D [2,4 C :|
which was remarkably readable (unlike some of Glen's stunts). But the
amount of structural analysis required to use such a feature is far
beyond what most ABC coders do. It might get more use if we had editing
tools that could identify common sections and create variant-repeat
structures to make more compact notation, but as yet we don't.
+| At present, when it encounters a repeat BarFly searches backwards for
+| one of the following symbols: |:, ||, |], [|, a P: field, or the start
+| of the tune. This seems to give the least problems, but it does mean
+| that you can't use a double bar or thin/thick bar within a repeat.
+ Going back to || or [| isn't a very good idea. It's common practice
+ to use double bars to mark the "major phrases" within a section, and
+ they are (almost) never used as repeat boundaries. The code should go
+ back to |: or the start of the tune. We oughta state this in the ABC
+ standard docs. This would both answer the question, and make life
+ easier for implementers.
...if those implementers didn't actually care whether their software could
handle existing ABC written years before they thought up this restriction.
A futureproof way of allowing repeats to cross double bars would be to
introduce a new kind of "repeat-transparent" double bar. This would
print the same way as || does, but would tell player programs to search
back past it for the start of the repeated section. That wouldn't break
any existing ABC (*all* of which has the semantics Phil described insofar
as the transcriber thought about it) but would allow transcribers to get
the behaviour John wants for new material. A sign like |.| or |:| would
do it.
? As a concrete suggestion for the multiple repeat syntax, how about:
? !4x!|: ... :|
I already suggested a syntax for it:
|4: ... :4|
which has the advantage of not using ! signs (a complete no-no given the
amount of ABC out there written for abc2win, which puts ! to a far more
productive use that would be much better adopted by any new standard).
It also has bracketing which humans or computers can use to check that
the transcriber hasn't forgotten something.
? The idea being that "4x" is attached to the immediately following start
? repeat by a printer program and detected as the repeat count by a player
? program.
CHARACTERS IN ABC SOURCE DON'T NEED TO GET PRINTED IN STAFF NOTATION!
As John Chambers says, a lot of users would rather have :: in the middle
of the staff. Others might like "4x", "4 defa" or whatever. Formatters
can generate any of them no matter what the ABC notation looks like, so
long as it's unambiguous, and a *good* formatter will give the user a
choice. The focus needs to be on designing a notation to be intrinsically
readable, helps avoid mistakes, and is easy to implement for whatever
purpose ABC might be put to. ASCII-fying a particular style of staff
notation isn't going to get there.
=================== <http://www.purr.demon.co.uk/jack/> ===================
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
