Re: What is the problem with "\relative"? (Was: Do we really offer the future?)

[Hwaen Ch'uqi]

Greetings,

The reasons for one not using relative mode are clear, but it hardly
justifies calling for its deprecation. As a composer of primarily
piano music, it is an absolute lifesaver. And all to whom I have
introduced LilyPond, primarily pianists or harpists, immediately
gravitated to relative mode. Again, why deprecate it when you have the
option of simply not using it?

Hwaen Ch'uqi


On 4/22/15, Kieren MacMillan <address@hidden> wrote:
> Hi Gilles,
>
>>> deprecate \relative, which I now avoid like the plague.
>> Why?
>
> 1. It doesn’t play well with reuse: both trivial reuse (i.e., cut-and-paste)
> and more advanced (i.e., referenced in variables) require extra care at the
> very least, and outright extra work (e.g., octave checks, transposition,
> etc.) in most cases. This means that sharing bits of music either within a
> file/piece or between files/pieces (or even between users) requires extra
> work and is error-prone.
>
>
> 2. It makes what should be simple adjustments unnecessarily complicated,
> with unnecessarily large impacts. Consider, as just one example, my paired
> functions
>
> split =
> #(define-music-function (parser location music1 music2)
>    (ly:music? ly:music?)
>    #{ <<
>          { \voiceOne $music1 }
>          \context Voice = "2" { \voiceTwo $music2 }
>       >> \oneVoice
>    #})
>
> splitLU =
> #(define-music-function (parser location music1 music2)
>    (ly:music? ly:music?)
>    #{ <<
>          { \voiceTwo $music1 }
>          \context Voice = "2" { \voiceOne $music2 }
>       >> \oneVoice
>    #})
>
> These (and their 3- and 4-voice counterparts) are workhorses in my code,
> saving me endless amounts of typing constructs like
>
>     << { \voiceOne foo } \new Voice { \voiceTwo bar } >> \oneVoice
>
> every time I simply want a short polyphonic section. I could hardly begin to
> do efficient engraving work without them. Now consider the effect of
> switching, in relative mode, from
>
>    b4 \split { a4 } { c,4 }
>
> to
>
>    b4 \splitLU { c,4 } { a4 }
>
> Because relative mode “leaves from” whatever pitch comes immediately before
> it, the first example would output the b followed by a sixth “chord"
> immediately below it (i.e., with the a on top, sitting a second below the
> b), whereas the second example would output the b followed by a third [!!]
> “chord" (i.e., with the c, on top, sitting a seventh below the b). In
> absolute mode, I am free to choose either function (and each is necessary!)
> at will, without worrying that the choice may mess up the outputted pitches.
>
> This same sort of relative shifting happens when you want to switch the
> order of notes as given in a chord, e.g. <c g’ b> outputs a different chord
> than <c b g’>.
>
>
> 3. Many single edits suddenly require two (or more) edits as a result solely
> of relative mode. For example, let’s say you have
>
>     \relative c’ { c d e a }
>
> and you want to change the e to d. Now you must also add an apostrophe to
> the a, to compensate for the relative octave adjustment:
>
>     \relative c’ { c d d a’ }
>
> wasting effort and brainpower (if you even remember to do it the first time,
> rather than compiling before finding the error).
>
>
> These are only three of the problems. Worst of all, having it is a false
> economy: it’s not actually intuitive for everyone (though it is for me, and
> was right away), as a quick search of the archives will turn up many newbies
> complaining about “how hard it is to remember when to use , and when to use
> ‘ and when to use nothing”.
>
> Yes, it’s a little more work during initial entry of some music to add the
> correct octavation to the pitches. But the majority of pitches I enter fall
> between c, and b’’, so the difference (if any) is minimal. And of course
> there are many patterns which require *more* octavation typing in relative
> mode than absolute, so in those cases absolute mode saves keystrokes.
>
> Hope this helps explain why I don’t use \relative any more, and tell most
> newbies I know to avoid it.
>
> Cheers,
> Kieren.
>
> ________________________________
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: address@hidden
>
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>