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
types.
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 <lilypond@hillvisions.com>, wrote:
I am uncertain what you mean by "proper" markup syntax.