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