[EMAIL PROTECTED] writes:
> | = stem 2
>
> The two stems *must* line up, and don't. This looks very seriously bad.
> It should have been taken care of 0.6 or 0.7 or something. It is scary
> that it arises in 1.x.
>
I know about it, but it's not on the top of my priority list. And
really, you don't wanna know what pre 1.x looked like.
> I would really like to contribute to a howto notate. I am not up to
> speed as a programmer, nor do I know enough linux, but I am very willing
> to have a go at it, one thing at a time. To be useful, it will have to
> be brief. It would be impossible without examples, and they should not
> be subject to changes of version, so what format would be good for the
> pictures? I can be very terse when I am not trying to be rhetorical and
> convince someone of that of which I'm not sure they want to be
> convinced.(!?) :-)
I am not sure about formats. ASCII pictures (like the one in this
email) can also serve as useful examples. Another possibility is
documenting notation as far as LilyPond supports it. For example,
have a look at
http://www.cs.uu.nl/people/hanwen/lilypond/Documentation/metadoc/out-www/regression-test.html
A third option is to make use of scanned images. In that case a
website would be the best option.
> Good typesetting is better than bad engraving would be a better way to
> put it, as you say. I have a sneaking suspicion that you have not seen
> enough bad engraving, or perhaps not enough bad things in good
> engraving. :-)
:)
I've seen lots of bad engraving AND lots of bad typesetting.
Remember, I also play french horn in an orchestra. Modern scores are
either in (often bad) hand writing or atrocities produced in Finale,
Mosaic, etc.
> I have not been trying to convince you that I have any expertise or
> anything like that, but rather that there is no authority either in
> precept or example on which you can rely, except for bad examples. You
> must rely on reasoned judgement alone.
[more, snipped]
Lots of your observations on the ambiguity of music notation and bad
taste in engraving are justified. But we do not have the authority to
change the old (and bad) ways of notation. In order to get such an
authority, we have to gather users and show we have know-how. I want
to do this by first catering for the `old' notation, however weird the
system might be.
> How did you get a copy of Ross? It was(is?) out of print for decades. I
> was not able to get one *when I cared*.
I ordered one at my local music store. It looked a little worn, so
maybe it has been on a shelf for a few decades. Someone on the SCORE
mailing list also managed to get hold of a copy for $30 if I recall
correctly.
> Chlapik and Ross are total incompetents at writing engraving software.
[..]
> If a rule can not be implemented with logic and consistency, it
> is a bad rule, and it ought not to be implemented at all. If you
> want to dig a hole, you have to
You are simplifying things here. A big part of the errors in LilyPond
output are not there because the rules are too complicated, but rather
because of lacking infrastructure: C++ objects method invocations in
are a lousy way to express music notation, both for traditional and
new notation.
Put differently: we lack a formalism where can
formulate music notation in a clear and unambiguous way: defining that
formalism is the big challenge in writing a music typesetter.
I hope that in the (distant) future we will have such a formalism
(this is one of the reasons for GUILE integration). If we can
express varieties of music notation easily, it is much easier to
experiment with alternative notation.
> Could be a short cut meaning:
>
> =========
> | | |*|
> | | *| \______
> | *| \_______
> *| \__________
> \__________
>
> I wouldn't put this past Dvorak at all. He was at the right time for it.
I've seen the latter often, especially as a notation for arpeggios (I
think it is abuse of notation, BTW).
--
Han-Wen Nienhuys, [EMAIL PROTECTED] ** GNU LilyPond - The Music Typesetter
http://www.cs.uu.nl/people/hanwen/lilypond/index.html
