[Top][All Lists]

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

Re: TextSpanner usability improvements (was Re: Scheme predicative types

From: Martín Rincón Botero
Subject: Re: TextSpanner usability improvements (was Re: Scheme predicative types)
Date: Sat, 19 Sep 2020 09:31:25 +0200

I am uncertain what you mean by "proper" markup syntax. 

Sorry, I meant syntax for markup tagging. 
while interesting, is invalid syntax and surely not proper. Perhaps 
you simply meant something that *looks* like it could be valid LilyPond.

how can a proposed syntax (for which functions have to be written yet) as example be invalid? It surely has to look like it could be valid Lilypond!
Including all of these as 
parameters to a function could make the function unwieldy to use when 
one only needs to specify a few values. Optional arguments help to some 
degree, but they aren't perfect especially when there is ambiguity of 

At no point is my suggestion to “all” of these parameters in a function. My suggestion is to have a basic function with “sensible” defaults. They can always be tweaked or overridden by the user as desired. That’s what \override and \tweak are for.
And users of TextSpanners should invest in creating 
their own wrappers for commonly used items.

No they shouldn’t. They have to if they want to have a legible code with a proper markup tagging.
b'4 a' g'2\startTextSpan \with { left-text = "rit."
 to-barline = ##t } |
 f'4 g'8 a' g'2 | a'1\stopTextSpan }

I also was thinking of the better possibility that \startTextSpan can take arguments. The \with function is not meant for data input but for changing context properties. And if we’re starting to put text where it actually belongs in the music, certainly saying “left-text” for the \startTextSpan function is redundant. If \startTextSpan accepts text, \stopTextSpan should accept the right part of the text, so that it appears in the correct place in the music. A basic (hypothetical) c1\startTextSpan "left" c1 c1\stopTextSpan "right" would be a massive improvement in readability. If this function could stop being “misused” for tempo variations (if we had tempo spanners), then I suppose the italics by default could go away (I can’t think of other reason why they have to be italics by default!)
That approach would better preserve the semantics of the underlying 
elements. Consuming a \tempo command only to produce a \markup that 
*looks* like a MetronomeMark but is not one leads to issues as you found 
with MIDI. The Tempo_performer cannot do what it needs to do as it does 
not understand what the \markup means. That is not to mention that the 
use of \tempo occurs at the wrong moment in the music. Such a proposed 
MetronomeSpanner would terminate with an actual \tempo command on either 
end at the correct moments. And the Tempo_performer could be improved 
to understand how to interpolate tempos that are connected by spanners.

Yes, the script I started writing and that you splendidly finished is a workaround, not a solution. I’m not a programmer, so the day I can actually make a pull request for issues like these might never come. It would be great if such spanners can be implemented!
I wonder if the parser's \etc could support defining new functions that 
borrow the syntax from built-in ones:

That would be nice as well :-).
On 19. Sep 2020, 07:01 +0200, Aaron Hill <>, wrote:

I am uncertain what you mean by "proper" markup syntax.

reply via email to

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