Re: 2.10 questions

[Graham Percival]

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