--- Begin Message ---
|
Subject: |
Re: 2.10 questions |
|
Date: |
Sat, 2 Dec 2006 16:58:49 -0500 |
|
User-agent: |
KMail/1.9.1 |
Thanks for the reply!
The finger-crossing bezier thing happens with some files but not others. The
ones it happens with aren't particularly short, so I need to know what it's
responding to in order to reproduce it in a short file. Can I assume it has
to do with the more specific error that comes right before? If so, here goes:
In this case it has to do with a LyricExtender in a newly added lyrics
context. (The top voice splits of and keeps his vowel while the others go one
with more words):
warning: programming error: Spanner LyricExtender is not fully contained in
parent spanner VerticalAxisGroup
The section in question is something like this:
%in a voice that later winds up being \voiceOne in a ChoirStaff:
tenor = { a4 b c d e f g
{ g g e1~ e e e e e e e e e }
\new Lyrics \lyricmode {
\set alignAboveContext="top"
% "Top" is name of the staff "tenor" is on %%
Wait4 for me!1*10 __ }
g4 e f d c b a }
Thus the lyrics, ending with a long extender, go with some nested-bracketed
notes, since after his solo single note, the tenor returns to agreement with
the others.
Somehow LP doesn't like the LyricExtender hanging out up there, I guess.
Could something like this have to do with Bezier Intersections and crossed
fingers?
Thanks for all your work.
Fr. P
On Saturday 02 December 2006 03:26, you wrote:
> 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
--- End Message ---