[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make metronomeMarkFormatter more flexible (issue 327620043 by addres

From: lilypond
Subject: Re: make metronomeMarkFormatter more flexible (issue 327620043 by address@hidden)
Date: Tue, 10 Oct 2017 11:47:13 -0700

Reviewers: dak,

On 2017/10/10 16:29:05, dak wrote:
I think this approach is a rather bad tradeoff between additional
properties and actual flexibility: it still only allows for a very
subset of metronome marks.

That’s true. BTW, I don’t even know why tempoHideNote and the properties
of this snippet and patch are context properties and not properties of

I think it would make sense to check all forms a \tempo mark currently
can take
and then see what principal forms those can assume.

Something like that?

\tempo "Allegro"             → Allegro
\tempo 4 = 120               → 𝅘𝅥 = 120
\tempo "Allegro" 4 = 120     → Allegro (𝅘𝅥 = 120)
\tempo 4 = 120-132           → 𝅘𝅥 = 120 – 132
\tempo "Allegro" 4 = 120-132 → Allegro (𝅘𝅥 = 120 – 132)
\tempo "" 4 = 120            →  (𝅘𝅥 = 120)       [misaligned]
\tempo "" 4 = 120-132        →  (𝅘𝅥 = 120 – 132) [misaligned]

I’m not sure what you mean by “principal forms”. Could you explain? I
made a list of limitations that the metronome mark formatter currently

• font
  – size
    ∘ everything can be scaled by grob property font-size
    ∘ text can then be scaled independently by markup commands
    ∘ note/numbers cannot be scaled independently
  – series
    ∘ numbers can be made bold by grob property font-series
    ∘ text doesn’t respect the grob property, can be made medium by
markup command
• brackets
  – type
    ∘ only round brackets
  – presence
    ∘ present if text is set
    ∘ text but no brackets: impossible
    ∘ no text but brackets: possible but misaligned because of leading
• note
  – stem
    ∘ only up
  – duration
    ∘ only one note, no ties
    ∘ only simple durations, no tuplets
• number
  – type
    ∘ only integer (floating point is not nice to print as pointed out
on the user list some time ago but rationals might be wanted)
  – range
    ∘ dash is hardcoded (endash surrounded by thin spaces)
• equation
  – equation sign
    ∘ sign is hardcoded (= surrounded by spaces), so neither other signs
like ≈ or ≥ nor text like “= approx.” are possible
  – type
    ∘ only “note = number”/“note = range”, not “note = note”
• miscellani
  – swing feeling
    ∘ not really a tempo indication, but 8 8 = \tuplet 3/2 { 4 3 } and
others would be nice (see equation→type and note→duration)

Then, one needs to look how
many basically different format functions it makes sense to specify
for those
forms and pass those the _raw_ information in the \tempo mark, making
responsible for proper formatting.

So you don’t want grob and context properties for the fine tuning but
different functions? That sound like an awful lot of functions to me
(similar to the rehearsal mark formatters).

That's for formatting: probably something needs to be there in
parallel for
calculating the moments-per-minute value.

Yes, that would be nice.

Maybe we want something like

\tempo { \tuplet 2/3 { 4 8 } } = 45

to work as well?  That would require yet another hook.

What is this supposed to mean/look like? Does it mean \tempo 4 = 45 or
\tempo 4*2/3 = 45? Should this output one quarter note or two notes?

make metronomeMarkFormatter more flexible

This adds the context properties tempoEquationText, tempoBetweenText and
tempoShowParentheses as shown in

It also allows to scale the size of the notes in a metronome mark
independently from or rather relatively to the text and numbers.
I added this possibility because
suggests smaller note sizes; so there seems to be a need for that.

The default values are chosen so that the whole thing is backwards
compatible; to achieve this, tempoShowParentheses accepts not only
boolean values but also the symbol 'if-text.

I chose the name tempoShowParentheses instead of tempoHideParentheses
because this property also allows parenthesizing text-less

Contains regtests.

Please review this at

Affected files (+94, -16 lines):
  A input/regression/
  A input/regression/
  M lily/
  M scm/define-context-properties.scm
  M scm/translation-functions.scm

reply via email to

[Prev in Thread] Current Thread [Next in Thread]