make metronomeMarkFormatter more flexible

make metronomeMarkFormatter more flexible

This adds the context properties tempoEquationText, tempoBetweenText and
tempoShowParentheses as shown in http://lsr.di.unimi.it/LSR/Item?id=1008

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 http://lsr.di.unimi.it/LSR/Item?id=1008
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
MetronomeMarks.

Contains regtests.

[dak, 2017-10-10 16:29:05]

I think this approach is a rather bad tradeoff between additional context
properties and actual flexibility: it still only allows for a very limited
subset of metronome marks.

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.  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 them
responsible for proper formatting.

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

Maybe we want something like

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

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

[Malte Meyn, 2017-10-10 18:47:14]

On 2017/10/10 16:29:05, dak wrote:
> I think this approach is a rather bad tradeoff between additional context
> properties and actual flexibility: it still only allows for a very limited
> 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 MetronomeMark.

> 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 has:

• 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 space
• 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 them
> 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?

[x.scheuer_gmail.com, 2017-10-11 08:30:46]

Hello,

It is nice to see you working on adding new functionalities directly
into LilyPond, thanks.

Just FYI there are also all these Rhythm marks / play style indication
shown in LSR #204 http://lsr.di.unimi.it/LSR/Item?id=204

Cheers,
Xavier


On 10 October 2017 at 20:47, <lilypond@maltemeyn.de> wrote:

> Reviewers: dak,
>
> Message:
> On 2017/10/10 16:29:05, dak wrote:
>
>> I think this approach is a rather bad tradeoff between additional
>>
> context
>
>> properties and actual flexibility: it still only allows for a very
>>
> limited
>
>> 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
> MetronomeMark.
>
> 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
> has:
>
> • 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
> space
> • 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
>>
> them
>
>> 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?
>
> Description:
> make metronomeMarkFormatter more flexible
>
> This adds the context properties tempoEquationText, tempoBetweenText and
> tempoShowParentheses as shown in http://lsr.di.unimi.it/LSR/Item?id=1008
>
> 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 http://lsr.di.unimi.it/LSR/Item?id=1008
> 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
> MetronomeMarks.
>
> Contains regtests.
>
> Please review this at https://codereview.appspot.com/327620043/
>
> Affected files (+94, -16 lines):
>   A input/regression/metronome-mark-formatter-extended.ly
>   A input/regression/metronome-mark-note-size.ly
>   M lily/metronome-engraver.cc
>   M scm/define-context-properties.scm
>   M scm/translation-functions.scm
>
>
>
> _______________________________________________
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>



-- 
Xavier Scheuer <x.scheuer@gmail.com>

[dak, 2017-10-11 08:34:54]

Xavier Scheuer <x.scheuer@gmail.com> writes:

> Hello,
>
> It is nice to see you working on adding new functionalities directly
> into LilyPond, thanks.
>
> Just FYI there are also all these Rhythm marks / play style indication
> shown in LSR #204 http://lsr.di.unimi.it/LSR/Item?id=204

Bit of a challenge to find good input syntax for it and something to map
it through.

-- 
David Kastrup

[Malte Meyn, 2017-10-12 06:22:22]

On 2017/10/10 18:47:14, Malte Meyn wrote:
> > 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.
> 
> […]
> 
> 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 has:

This is a huge list and I’m not sure everything in that list should be supported
(and probably I missed some other things that should). So I think we need a
collection of real-world examples, or—easier—look into Gould’s “Behind Bars” or
similar literature as a reference. There we might also find how to handle
tuplets and tied notes. Unfortunately I don’t own a copy of that book.

[dak, 2017-10-12 07:23:51]

On 2017/10/12 06:22:22, Malte Meyn wrote:
> On 2017/10/10 18:47:14, Malte Meyn wrote:
> > > 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.
> > 
> > […]
> > 
> > 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 has:
> 
> This is a huge list and I’m not sure everything in that list should be
supported
> (and probably I missed some other things that should).

Well, with regard to "should be specifically supported", I'll give you an
emphatic "of course not".  The question is how to make it easiest for users to
do the specific support on their own.  Should we provide markup functions for
the various elements?  Then you can just
\tempo \markup ...
your own mark together.  In that case: how do we do the Midi version?  We could
just rely on
\hide \tempo 4. = 60
or similar for that for now.  Not particularly pretty but workable.  But then we
would need to support simultaneous tempo events as long as they don't produce
competing visuals or speeds (separate issue, we don't need to include this here
but it would mean that we can focus on the markup and not worry about the Midi).

[Malte Meyn, 2017-10-12 08:04:49]

On 2017/10/12 07:23:51, dak wrote:
> Should we provide markup functions for
> the various elements?  Then you can just
> \tempo \markup ...
> your own mark together.

That solution would need only one new thing: A markup command \rhythm that works
as extended \note and takes not one but several durations, ties, tuplets, and
beams. And maybe one could make the alignment of \note/\rhythm so that you don’t
need \general-align?

And I really would like to have the tempoShowParentheses context property
because it’s really common to see tempo both with and without parentheses and
IMHO it’s weird to have to write
    \set Score.tempoHideNote = ##t
    \tempo \markup \concat { "Allegro " \note { 4 } " = 120" } 4 = 120
only because you don’t want parentheses.

Maybe it would be nice to have markup commands for the symbols ≈ and ≙ (the
latter for something like 𝅘𝅥 ≙ 𝅗𝅥 if you don’t like = here), one would have to
discuss which symbols are really needed.

> In that case: how do we do the Midi version?  We could
> just rely on
> \hide \tempo 4. = 60
> or similar for that for now.

That’s what we have tempoHideNote for, isn’t it?

> Not particularly pretty but workable.  But then we
> would need to support simultaneous tempo events as long as they don't produce
> competing visuals or speeds (separate issue, we don't need to include this
here
> but it would mean that we can focus on the markup and not worry about the
Midi).

There is one case I really would like more than the \markup based solution for:
tempo equivalences like 𝅘𝅥 = 𝅗𝅥. And because that also sometimes requires markup
fine tuning by the user one could make another command that acts like \tempo but
takes a duration instead of a number or range:

\tempo "Allegro" 4 = 120
R1
\tempoEquiv "L’istesso tempo" 2 = 4
R
\set Score.tempoHideNote = ##t
\tempo \markup \concat { "Allegro rubato (" \note { 4 } " ≈ 120)" 4 = 120
R
\tempoEquiv \markup \concat { "Le double plus lent, " \note { 16 } " = " \note {
8 } " précédente" } 16 = 8
R

That would output
    Allegro (𝅘𝅥 = 120)
    L’istesso tempo (𝅗𝅥 = 𝅘𝅥)
    Allegro rubato (𝅘𝅥 ≈ 120)
120 𝅘𝅥𝅯 = 𝅘𝅥𝅮 précédente

That

[Malte Meyn, 2017-10-12 08:07:08]

I accidentally hit “Send Message” … Here is the last paragraph again and fixed:


That would output
    Allegro (𝅘𝅥 = 120)
    L’istesso tempo (𝅗𝅥 = 𝅘𝅥)
    Allegro rubato (𝅘𝅥 ≈ 120)
    Le double plus lent, 𝅘𝅥𝅯 = 𝅘𝅥𝅮 précédente
and have following tempo for MIDI
    4 = 120
    2 = 120
    4 = 120
    8 = 120

[Malte Meyn, 2017-10-12 08:19:52]

On 2017/10/12 08:04:49, Malte Meyn wrote:
> And I really would like to have the tempoShowParentheses context property
> because it’s really common to see tempo both with and without parentheses and
> IMHO it’s weird to have to write
>     \set Score.tempoHideNote = ##t
>     \tempo \markup \concat { "Allegro " \note { 4 } " = 120" } 4 = 120
> only because you don’t want parentheses.

Another suggestion regarding this point: Don’t call that tempoHideParentheses or
tempoShowParentheses but tempoParenthesizeNote or something similar.
tempoHideNote hides a note that is only there when the user inputs it. But
parentheses aren’t input by the user so they might be confused which parentheses
this property is talking about.

[dak, 2017-10-12 08:24:36]

On 2017/10/12 08:19:52, Malte Meyn wrote:
> On 2017/10/12 08:04:49, Malte Meyn wrote:
> > And I really would like to have the tempoShowParentheses context property
> > because it’s really common to see tempo both with and without parentheses
and
> > IMHO it’s weird to have to write
> >     \set Score.tempoHideNote = ##t
> >     \tempo \markup \concat { "Allegro " \note { 4 } " = 120" } 4 = 120
> > only because you don’t want parentheses.
> 
> Another suggestion regarding this point: Don’t call that tempoHideParentheses
or
> tempoShowParentheses but tempoParenthesizeNote or something similar.
> tempoHideNote hides a note that is only there when the user inputs it. But
> parentheses aren’t input by the user so they might be confused which
parentheses
> this property is talking about.

Well, we could have tempoParentheses set to \markuplist { "(" ")" } by default. 
That's pretty general, except for just where the parentheses appear.

[Malte Meyn, 2017-10-12 08:27:51]

How would that reflect that parentheses are shown if and only if text is
present? And how could you then change this behaviour?

[dak, 2017-10-12 08:53:31]

On 2017/10/12 08:27:51, Malte Meyn wrote:
> How would that reflect that parentheses are shown if and only if text is
> present? And how could you then change this behaviour?

Pass.  For more extensive changes, we'd need a markup function.  Basically,
where we can go from some reasonably easy

\tempo \markup \specificFormatter { "(" "=" ")" } {4} #128

in single-use cases to

\override Staff.TempoFormatter = \markup \specificFormatter { "(" "=" ")" } \etc

in general.  We "just" have to figure out what this is supposed to be
called/callable with, how many of those hooks we really need, and how many
specific formatters we should provide out of the box.

[thomasmorley651, 2017-10-12 21:54:00]

On 2017/10/12 08:53:31, dak wrote:
> On 2017/10/12 08:27:51, Malte Meyn wrote:
> > How would that reflect that parentheses are shown if and only if text is
> > present? And how could you then change this behaviour?
> 
> Pass.  For more extensive changes, we'd need a markup function.  Basically,
> where we can go from some reasonably easy
> 
> \tempo \markup \specificFormatter { "(" "=" ")" } {4} #128
> 
> in single-use cases to
> 
> \override Staff.TempoFormatter = \markup \specificFormatter { "(" "=" ")" }
\etc
> 
> in general.  We "just" have to figure out what this is supposed to be
> called/callable with, how many of those hooks we really need, and how many
> specific formatters we should provide out of the box.

I'd like to suggest a little different.
Sometimes I've the feeling we add more and more specialized context- and
grob-properties in direct contradiction to the goal to "unify"
grob/context-properties. Why not use sub-properties of 'details and let the
printing-function call a markup-command accessing and processing them?

Here an example. Although it puts out a dummy only, the markup-command has full
access to the details-properties and could _do_ something with it.

#(define-markup-command (tempo-test layout props)()
  
  (pretty-print (ly:chain-assoc-get 'details props))
  
  (interpret-markup layout props "tempo-dummy"))

\layout {
  \context {
    \Score
    metronomeMarkFormatter = #(lambda (evt ctx) (make-tempo-test-markup))
  }
}
  
{
  \override Score.MetronomeMark.details = 
    #(list
      (cons 'between-text " – ")
      (cons 'equal-sign " = ")
      (cons 'parentheses? #f)
      (cons 'note-size -1)
      )
  \tempo 8=120
  R1
}

What do you think?

[kieren_macmillan_sympatico.ca, 2017-10-13 05:10:38]

Hi Harm,

> I'd like to suggest a little different.
> [...]
> What do you think?

Although I don't understand the internals as well as any of you, on first glance
this approach looks incredibly promising! If it would be flexible enough to
handle "wacky" things like

  [<– Q = Q. –>] Poco meno mosso (Q. = 120), rubato

then it's a no-brainer.

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: info@kierenmacmillan.info

[Malte Meyn, 2017-10-15 08:51:31]

On 2017/10/12 21:54:00, thomasmorley651 wrote:
> {
>   \override Score.MetronomeMark.details = 
>     #(list
>       (cons 'between-text " – ")
>       (cons 'equal-sign " = ")
>       (cons 'parentheses? #f)
>       (cons 'note-size -1)
>       )
>   \tempo 8=120
>   R1
> }
> 
> What do you think?

I like it IFF this means you’re able to override single entries of this list:
    \override Score.MetronomeMark.details.note-size = -5
But I’d suggest not to use a ‘?’ here but call it parenthesize (if it is given a
boolean? or boolean-or-symbol? as I suggested above) or parentheses without a
‘?’ (if it is given a markuplist as David suggested). Maybe use both?
    \override Score.MetronomeMark.details.parenthesize = #'if-text
    \override Score.MetronomeMark.details.parentheses = \markuplist { "[" "]" }
I don’t think “wacky” things like Kieren’s example can be done like this but you
could do such complicated things as you could before by simply using a markup in
the \tempo.

I’d suggest to only handle “note = number” tempos here and open another issue
for “note = note” tempos. There we could discuss whether to have a new command
\tempoEquiv or use the “old” \tempo but with a different syntax like \tempo 4 ~
2.

[Malte Meyn, 2017-10-15 09:31:37]

Maybe we should think about another subproperty for text like "M. M." that is
placed before the note but after the opening parenthesis if there is one. This
can be neither in the tempo text (\tempo "Allegro M. M." 4 = 120 would put it
before the parenthesis) nor in the parenthesis text (\tempo 4 = 120 would omit
it).

[dak, 2017-10-15 09:36:25]

On 2017/10/15 09:31:37, Malte Meyn wrote:
> Maybe we should think about another subproperty for text like "M. M." that is
> placed before the note but after the opening parenthesis if there is one. This
> can be neither in the tempo text (\tempo "Allegro M. M." 4 = 120 would put it
> before the parenthesis) nor in the parenthesis text (\tempo 4 = 120 would omit
> it).

I think it's rather obvious that we won't get something that caters for every
format without actually giving the user the equivalent of providing a formatting
function (in the form of a markup command): even a format string requires a
certain order of elements.

We might provide a stock formatting function that consults the details and thus
can cater for the most common use cases.  But trying to capture all is just
going to make for an incomprehensible and complex interface that still does not
work for all use cases.

[kieren_macmillan_sympatico.ca, 2017-10-15 13:09:30]

Hi David,

> I think it's rather obvious that we won't get something that caters for
> every format without actually giving the user the equivalent of
> providing a formatting function (in the form of a markup command): even
> a format string requires a certain order of elements.
> 
> We might provide a stock formatting function that consults the details
> and thus can cater for the most common use cases.  But trying to capture
> all is just going to make for an incomprehensible and complex interface
> that still does not work for all use cases.

I'm so glad you said this! This is exactly what I suggested to Harm (off-line),
and I think it's precisely the way to accomplish the best of all possible
worlds.

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: info@kierenmacmillan.info

[thomasmorley651, 2017-10-15 19:50:50]

On 2017/10/10 18:47:14, Malte Meyn wrote:

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

Why misaligned? Could you give an example?

[thomasmorley651, 2017-10-15 20:03:08]

On 2017/10/15 13:09:30, kieren_macmillan_sympatico.ca wrote:
> Hi David,
> 
> > I think it's rather obvious that we won't get something that caters for
> > every format without actually giving the user the equivalent of
> > providing a formatting function (in the form of a markup command): even
> > a format string requires a certain order of elements.
> > 
> > We might provide a stock formatting function that consults the details
> > and thus can cater for the most common use cases.  But trying to capture
> > all is just going to make for an incomprehensible and complex interface
> > that still does not work for all use cases.
> 
> I'm so glad you said this! This is exactly what I suggested to Harm
(off-line),
> and I think it's precisely the way to accomplish the best of all possible
> worlds.

On the tracker I posted a more elaborated code.
https://sourceforge.net/p/testlilyissues/issues/5215/#e472

[kieren_macmillan_sympatico.ca, 2017-10-16 03:23:04]

Hi Harm (et al.),

> On the tracker I posted a more elaborated code.
> https://sourceforge.net/p/testlilyissues/issues/5215/#e472

Hmmm… That's not at *all* what I was hoping that would look like.

I was hoping it could be more like a custom bookTitleMarkup, by leveraging
\fromproperty [warning: obviously pseudo-code, but close to an interface that
would make sense to me]:

  metronome-mark-formatter = \markup {
    \concat {
      \fromproperty MetronomeMark.details.left-paren
      \hspace #0.25
      \note \fromproperty MetronomeMark.details.note
      \hspace #0.3 \fromproperty MetronomeMark.details.equal-sign \hspace #0.3
      \fromproperty MetronomeMark.details.mm-range-begin "–" \fromproperty
MetronomeMark.details.mm-range-end
      \fromproperty MetronomeMark.details.left-paren
    }
  }

Is nothing closer to that possible?

Thanks,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: info@kierenmacmillan.info

[dak, 2017-10-16 07:29:16]

On 2017/10/16 03:23:04, kieren_macmillan_sympatico.ca wrote:
> Hi Harm (et al.),
> 
> > On the tracker I posted a more elaborated code.
> > https://sourceforge.net/p/testlilyissues/issues/5215/#e472
> 
> Hmmm… That's not at *all* what I was hoping that would look like.
> 
> I was hoping it could be more like a custom bookTitleMarkup, by leveraging
> \fromproperty [warning: obviously pseudo-code, but close to an interface that
> would make sense to me]:
> 
>   metronome-mark-formatter = \markup {
>     \concat {
>       \fromproperty MetronomeMark.details.left-paren
>       \hspace #0.25
>       \note \fromproperty MetronomeMark.details.note
>       \hspace #0.3 \fromproperty MetronomeMark.details.equal-sign \hspace #0.3
>       \fromproperty MetronomeMark.details.mm-range-begin "–" \fromproperty
> MetronomeMark.details.mm-range-end
>       \fromproperty MetronomeMark.details.left-paren
>     }
>   }
> 
> Is nothing closer to that possible?

Well, for one thing you'd leave off "MetronomeMark." since you don't get a
choice of which grob you'll get.  For another, I don't think `\fromproperty`
does nested properties, but it might be reasonably easy to teach it how to do
them.  From a usability standpoint, I think this proposal beats mine that was
going to use a markup function with a sequence of basically unnamed arguments. 
Creating a markup is quite more user-accessible terrain than creating a markup
function, and this way one does not need to look up argument order.

[Malte Meyn, 2017-10-30 07:44:49]

On 2017/10/15 19:50:50, thomasmorley651 wrote:
> On 2017/10/10 18:47:14, Malte Meyn wrote:
> 
> > \tempo "" 4 = 120            →  (𝅘𝅥 = 120)       [misaligned]
> > \tempo "" 4 = 120-132        →  (𝅘𝅥 = 120 – 132) [misaligned]
> 
> Why misaligned? Could you give an example?

Have a look at the regtest output James added to
https://sourceforge.net/p/testlilyissues/issues/5215/. It looks like there is a
space which comes between the (here empty) tempo text and the opening
parenthesis.

But I must admit I cannot reproduce this misalignment. When I compile this
single regtest file with 2.19.65 it looks ok. Only when compiled using make test
it doesn’t. Strange.

Apart from that I posted a code at
https://sourceforge.net/p/testlilyissues/issues/5215/#505b that tries to go into
the direction of Kieren’s latest suggestion.

[dak, 2017-10-30 07:53:19]

lilypond@maltemeyn.de writes:

> On 2017/10/15 19:50:50, thomasmorley651 wrote:
>> On 2017/10/10 18:47:14, Malte Meyn wrote:
>
>> > \tempo "" 4 = 120            →  (𝅘𝅥 = 120)       [misaligned]
>> > \tempo "" 4 = 120-132        →  (𝅘𝅥 = 120 – 132) [misaligned]
>
>> Why misaligned? Could you give an example?
>
> Have a look at the regtest output James added to
> https://sourceforge.net/p/testlilyissues/issues/5215/. It looks like
> there is a space which comes between the (here empty) tempo text and the
> opening parenthesis.
>
> But I must admit I cannot reproduce this misalignment. When I compile
> this single regtest file with 2.19.65 it looks ok. Only when compiled
> using make test it doesn’t. Strange.

There have been changes in the tempo formatting to better cater for
SVG.  It is likely that those changes are at fault.

-- 
David Kastrup

[Malte Meyn, 2017-10-30 15:20:07]

On 2017/10/30 07:44:49, Malte Meyn wrote:
> Apart from that I posted a code at
> https://sourceforge.net/p/testlilyissues/issues/5215/#505b that tries to go
into
> the direction of Kieren’s latest suggestion.

This approach would work if it didn’t have to collect all needed information
from grob, context and event properties but only from grob properties.
Currently, the grob property 'text is set by the metronomeMarkFormatter which
takes input from event (f. e. 'text) and context (f. e. 'tempoHideNote)
properties.

Ok, technically, it’s possible to get the other properties (as one can see at
the bottom of that code example, but that would be really confusing (I don’t
know a better word for the German “unübersichtlich”).