2010/6/19 Kieren MacMillan <kieren_macmil...@sympatico.ca>:
> Hey y'alls,
>
> I'm trying to solve the age-old [for me] problem of MetronomeMark
> placement.
:-)
I complained a lot about the bad "tempo indications" placement, I'm
really glad to see people trying to solve it.
Thanks!
> There are [at least] four issues that need to be solved simultaneously:
> (1) MMs [almost always] need to be at the top of each system;
Well, this is already the case, isn't it?
"Staff_collecting_engraver" takes care of that for both RehearsalMark
and MetronomeMark, which is fine.
> (2) MMs potentially need to be other places (e.g., bottom of each
> system, or mid-system between two staff groups);
Ususally, when not printed at the top of the whole system it is (based
on my own experience with scores from IMSLP):
a. either printed at the top and at the bottom of the whole system,
which is not possible to do _correctly_ right now.
We could use the trick of LSR 10 but that would simply add
"Metronome_mark_engraver" to the lowest staff, and won't handle
correctly the case of removed Staff (\RemoveEmptyStaffContext).
To solve this I could imagine something like
\set doubleMetronomeMarks = ##t
(inspired by "\set doubleSlurs = ##t"), that would print MetronomeMark
at both the top and the bottom of the context it applies to (Score).
NOTE: The problem is *exactly* the same for RehearsalMarks !!!
That you be great to solve it the same way.
b. MM printed at the top of the whole system _and_ at the top of a
StaffGroup (normally "strings" for pieces like symphonies) inside
the system.
We can already handle this easily by adding
"Metronome_mark_engraver" to this StaffGroup and removing
"Staff_collecting_engraver" for the Score context.
c. MM printed at the top _and_ at the bottom of the whole system
*but also* at the top of a StaffGroup inside the system.
This is more complicated since it is a combination of both a & b.
So the possibility to use "doubleMetronomeMarks" within the Score
context should let the possibility _not to use it_ within the
StaffGroup. I have no idea how to make that possible.
By defining "doubleMetronomeMarks" as a property of the grob
MetronomeMark?
> (3) MMs should be baseline-alignable across any given system;
I did not go "that far" in my expectations...
> (4) These rules need to be followed regardless of which staves appear
> or disappear (cf \RemoveEmptyStaffContext).
Of course I agree.
But didn't "Staff_collecting_engraver" already take care of that?
(or should be supposed to)
> In the short term, I'm considering creating a Tempo context, which
> only prints out tempo indications (akin to the TimeSig context of
> yore). This context could then be placed in the \score wherever one
> needs it, solving (1), (2), and (4); since the context would be
> independent of any other contexts, (3) is automagically solved.
> But I want this to be easy to implement, so I either want the Tempo
> context to automagically ignore everything except MetronomeMark grobs,
> or I need to build a function/macro to strip out everything except
> MetronomeMark grobs.
I do not like this idea.
As Carl said, that would _constrain_ the user to have a separate music
expression to pass to the Tempo context... and I hate that!
We do not have a separate context for RehearsalMarks.
We have a separate "Dynamics" context for Piano centered dynamics
and I hate that...
That's not how it is supposed to work (IMO).
I would 100 times prefer to have it handled by a simple property change.
\override DynamicLineSpanner #'centered-between-staves = ##t
same for Metronome(+Rehearsal)Mark :
\override MetronomeMark #'baseline-align = ##t
but _keeping them in the normal (Staff) context_!
> Q#2: In the long term, would the short term solution still be the best,
> or should Lilypond Do The Right Thing™ in some other way that doesn't
> require a separate context?
I definitely agree.
Of course your Q#1 "separate context" solution could maybe be more
easily implemented, but from a user point of view this is awkward,
not intuitive and certainly unpleasant: that would constrain people to
separate the music into parts (notes, dynamics, indications, ...),
constrain them to use a \global variable and to play with spacer rests.
Of course you can "split" music into different variables if you want,
but I do not want this to become an "obligation".
We all want LilyPond to Do The Right Thing™. ;-)
Cheers,
Xavier
--
Xavier Scheuer <x.sche...@gmail.com>
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
