Re: MetronomeMark placement questions

[Xavier Scheuer]

2010/6/19 Kieren MacMillan <address@hidden>:

> 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 <address@hidden>