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

[David Wright]

On Mon 07 Aug 2017 at 08:43:31 (+0200), David Kastrup wrote:
> 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?

Were I to be deciding that, I would cut and paste this paragraph from
the LM and adjust the wording:
"Exactly the same happens even when any of these notes are sharpened or 
flattened. Acci-
dentals are totally ignored in the calculation of relative position. Precisely 
the same staff space
counting is done from a note at any other position on the staff."

So it would use the unmodified note names just as \relative and the
current implementation of \fixed do. As things are, \fixed effectively
throws away the note name of the reference pitch as well as
accidentals. The syntax could have been \fixed , { … } \fixed { … } \fixed ' { 
… }
with a "c" merely implied, because all it does is add the requisite
amount of poop and cancel out any contradictions.

> >> > 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.

Neither do I. But the post I was commenting on was constructing an
Aunt Sally argument, "the unpredictability of \relative with \tag"
as a reason to make the change.

> 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.

Guilty as charged.

> > 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.

Well, that's what I tried to do by removing the parts of the code
that had no bearing on \relative's behaviour but (a) were obscuring
the simple relation of the note pitches being input and (b) were
believed erroneously by the OP to have some influence on the pitches
of those notes.

> So he has
> all the necessary information for considering and/or trying and/or
> rejecting such a switch.

Oh come on. There are contributors here whose words carry far more
weight than many of us, and with good reason. Their posts get pasted
into archives and consulted later, so their accuracy is all the more
important.

> >> > 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,

Agreed. And I was just expressing how it might have been better,
in my opinion. As it is, I gain nothing over \relative so I
haven't used it.

> but that's exactly
> where \relative becomes markedly harder to write and read correctly.

Yes, but as a singer transcribing music, I can hum ahead and mentally
grok large intervals more easily than having to deal with octavation
every time I step over the b-c divide. This divide is firmly embedded
in music notation but not in the musical part of my brain.

But I'm not trying to dissuade anyone from using \absolute and, now,
\fixed. In fact, I was contradicted when I expressed an opinion that
it would be difficult to _compose_ directly into anything other than
\absolute because of all the cutting and pasting involved.

> >> 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?

I didn't say that. I said that you haven't shown it fails on one of
the core tenets of its justification merely because some humans have
difficulty learning/understanding/retaining the concept.

> So both telling them
> what \relative does and what alternatives are there seems like a
> reasonable approach to me.

Yes, but why cloud the issue with alternative facts about unpredictability?

> >> 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.

Hey, programming's hard. Glad I'm retired.

One way of reducing complexity for the users is to try and keep things
orthogonal, so that doing one thing doesn't lead to a side-effect
elsewhere. So if you believe a side-effect exists and try to exploit
it (like here where the OP thought that \tag could turn \relative
on and off), is it not best to disabuse the OP of the interaction
rather than leave them with, or even reinforce, the impression that
\tag is leading to unpredictability?

> 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.

So what you appear to be saying in these paragraphs is that \relative
doesn't play well with scheme programming. Two things occur to me:

LP should have a well-defined and predictable behaviour, and this
should be reflected in its documentation.

If one can't understand the definition, behaviour, upsides and
downsides of \relative, is there much hope of advancing into
scheme programming and how that interacts with LP?

Cheers,
David.