Re: Understanding how \tag works in \relative pitched music

[David Kastrup]

David Wright <address@hidden> writes:

> On Sun 06 Aug 2017 at 22:51:57 (+0200), David Kastrup wrote:
>> David Wright <address@hidden> writes:
>> 
>> > (\fixed could have been implemented differently, ie without
>> > collapsing the meaning of c' through b' as its first argument.
>> > This might make it more useful for parts having a limited range
>> > centered close to c.)
>> 
>> How so?  The reason we collapsed the meaning is that we had several
>> different opinions of what the natural behavior of \fixed f' should be
>> "obviously", so we punted by choosing behavior that did not provide
>> (possibly shortlived) usefulness for anything rather than c'''.
>
> As an example, some hymn tunes have alto parts of very limited range,
> barely a few notes. However, those notes frequently lie around middle C
> which means that both \fixed c and \fixed c' will have many octavation
> marks, either "'" or ",". However, were \fixed g { … } to mean that
> unmarked notes lie in the absolute range g through f', the number of
> marks required would be drastically reduced, which is how I was measuring
> usefulness. (I have no idea whether this methodology was one of the
> "obvious natural behaviours" that were considered and passed over.)

So what does \fixed fes' do to { disis e eis feses fes f } ?  What is
its natural interpretation?

>> > Anyway, would the people who like \absolute please be a little less
>> > evangelical about it.
>> 
>> Uh, where is the point?  This is a discussion group.
>
> Yes, but there seem to be occasional postings where the opinions come
> across as attempts at conversion rather than mere discussion.

So?  When people have problems with a particular construct that is
working as designed (we are not talking about shortcomings in the
implementation here) and alternative designs have proven better for
them, I see nothing wrong with reporting this.

It is true that there is a whole lot of repetition going on in this
mailng list that may be tiring to seasoned readers but may be due to the
same question coming up again and again and people not resolving it by
exhaustively searching the archives.  But that's also in the nature of a
list.

> I didn't want to be specific, but perhaps it's necessary for you—eg,
> "There are many, many other reasons I'm glad I switched to absolute
> (and \fixed), but this was a main one. You might consider doing the
> same?"

"you might consider" and "you should" are two different things, and it's
not like the list did not leave the questioner also with a fine-grained
explanation of what happens exactly when you use \relative.  So he has
all the necessary information for considering and/or trying and/or
rejecting such a switch.

>> > Some of us are happy using \relative, and understand how it
>> > interacts (or, more usually, doesn't) with other constructions in
>> > LP. It's odd that one of your main reasons for abandoning \relative
>> > was merely a misunderstanding of what it does, but I think that
>> > that could partly be blamed on its documentation. \relative's
>> > treatment of accidentals merits bold typeface in the LM; perhaps
>> > its existence as an immediate _input_ method could be similarly
>> > emphasised where appropriate.
>> 
>> \relative is a tool for expressing input.  As such, it should offer
>> significant clarity with regard to one aspect of input.
>
> And it succeeds in at least two for me. I've already mentioned one,
> the treatment of intervals across b-c. Another is preventing LP code
> looking like fly-shit language (cf Leaning Toothpick Syndrome).

\fixed is also pretty good at minimizing fly-shit.  It becomes worse in
that regard for stuff with widely navigated ranges, but that's exactly
where \relative becomes markedly harder to write and read correctly.

>> It doesn't do that impressively when communicating with other
>> programs, so its main incentive is communication with humans.  When
>> humans are confused about what it does, it fails on one of the core
>> tenets of its justification.
>
> That argument fails because not all humans are the same. The humans
> that are confused are those that don't seem to learn/understand/
> retain your sentence "\relative is a tool for expressing input."

Well, we can't tell them to drop dead, can we?  So both telling them
what \relative does and what alternatives are there seems like a
reasonable approach to me.

>> So its advantages are not without drawbacks, and people weighing in
>> on how those affect them respectively are making for a clearer
>> picture.
>
> I'd be interested to know whether you agree with "the unpredictability
> of \relative with \tag". I don't see it (as I expressed earlier), but
> would value your opinion as you've probably forgotten more about LP
> than I ever knew.

For me it's not "unpredictable" as I'm rather acquainted with its
internals and mechanism.  But that doesn't mean that I don't find it
"getting in the way" of usefully expressing things.

I explicitly designed the "make-relative" macro to make it easier for
people using music functions to let them behave reasonably naturally.
See

http://lilypond.org/doc/v2.19/input/regression/collated-files.html#make-relative.ly

for an example (click on the make-relative.ly link to see the source
code): the \relative version is easier to input and definitely reduces
"flyshit".  Without using make-relative, this would be completely
unusable in behavior.

Now make-relative is a convenient but quite heavy-handed macro.  There
are situations where it fails, and then it does so spectacularly.

The reason is that it allows creating a more natural "user experience"
by a totally unnatural and complex actual inner operation that has to be
defined individually for each music function written by the programmer.

This is a tradeoff, and one side of the tradeoff is definitely more
likely to strand users with question marks on their face on the lists.
Of course, if the alternative is to strand them with disgust on their
face with software not having a text input language at all, that's not
much of an improvement.

Now as people tend to work more and more with LilyPond, they tend to
become bit by bit more of a programmer rather than a mere user, work
less by trial and error, and cover more complex input sources with
multiple voices.  As they do, dealing with the complexities of \relative
and the resulting ripple effects of local source modifications and
reorganizations become more of a nuisance and one becomes more aware of
the _cost_ of fly-speck cleaning.

-- 
David Kastrup