Monk Panteleimon wrote:
1. It looks like hairpinToBarline is set "true" by default. The "changes" doc
makes it sound like you have to turn it on to get it to work:
Yes, true. It's a bit late to fix it now, but thanks anyway! :)
I assume that it was intended to be set ##t by default, and the docs are just
phrased from a 2.8 point of view. If this is so (here's the question) is it
##t by default because that's the common consensus of traditional old-school
engraving -- or is it just 'cause?
I think it was more of a "just 'cause" decision.
2. It looks like you can't put \tempo= inside \
midi{ } anymore.
...
The 2.10 manual (p 232) seems to say that only the \tempo command that goes
with the notes (producing a metronome mark unless forbidden to do so) affects
the tempo of the midi file. The manual's a little confusing here actually,
because the example shows the curly brackets empty for the midi block, and
tells us that in this example the tempo is set to 4=72. How? By leaving it
empty? So 72 is default? What am I missing?
Umm. Do you see that "FIXME" label right underneath the empty example?
That's the surest sign that the doc editor (i.e. me) has been slacking
off. In particular, he didn't do a search for "FIXME" signs just before
2.10 was released.
Fixed in the next release.
So, the only ways to set a tempo for the midi file without adding a metronome
mark are to add and a metronome mark, but make it invisible, or else do that
kind of longish thing with the scheme-indentifier in it, wherewith convert-ly
replaces the old \midi{ \tempo = ... } deal. Right?
Currently, yes.
Is there a shorter way, or can I somehow re-instate the 2.8 method in my
lilypond installation? I often make midi files, but rarely require a
metronome mark.
There was some discussion about having another way to set the tempo, but
the discussion fizzled out. Stay tuned for more info.
3. When I run 2.10 on any files (before or after convert-ly) I get lots of
messages that say "programming error: no solution found for Bezier
intersection, continuing, crossfingers"
The files still compile, but I wonder if it's okay to uncross my fingers now.
[8^)>
Programming errors are a bad sign -- I mean, it's our fault, not yours.
Please construct a small example that demonstrates the error and send
it to bug-lilypond; that will help us improve future versions of lilypond.
4. (the dumbest question of all) Why 2.10? What's wrong with 3?
A change of 2.x to 3.x is seen as a big step; in particular for
lilypond, increasing the initial number means that old files are very
likely to require manual updating (ie convert-ly can't handle the
changes). Since 2.10 didn't break a lot of old files, it was became
2.10. :)
Cheers,
- Graham
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
