lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed new available and recommended behavior of \relative


From: David Kastrup
Subject: Re: Proposed new available and recommended behavior of \relative
Date: Sun, 10 Mar 2013 09:50:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Evan Driscoll <address@hidden> writes:

> On 3/9/2013 7:31 PM, Jim Long wrote:
>> So if somehow I've made two consecutive correct postulates,
>> wouldn't a user who used the mnemonic:
>> 
>> "If no reference pitch is given, then the first pitch after
>> \relative is relative to f"
>> 
>> ...
>> 
>> So, addressing those who are put off by a perceived mixing of
>> absolute and relative music inside \relative {}, does this
>> mnemonic assuage your concerns:
>> 
>> "If \relative { ... } is specified without a reference pitch,
>> the reference pitch defaults to f."
>
>
> A day or two ago I said that as a new user I was against the change
> (but not by much or with any actually meaningful objection) on account
> of the mixing of absolute and relative. I didn't find the "the first
> note after \relative [inside or outside of {}] is interpreted as
> absolute" particularly compelling either for similar reasons. But I
> think I *have* been swayed by the "\relative f" arguments.

The problem I have with talking much about \relative f is that f seems
arbitrary.  However, maybe an explanation linking both of these concepts
and explaining how f is arrived at will allow both views to coexist.
Something like

    Relative mode can access exactly one octave around the reference
    pitch without using octave marks.  The octave of absolute notes
    written without octave marks, namely @code{c} to @code{b}, is
    centered on @code{f}, so the first note in a @code{\relative f}
    command is indistinguishable from being written in absolute mode.

    This is conventient enough to make @code{f} the default reference
    pitch for @code{\relative}.  As a rule of thumb, the first pitch
    after @code{\relative} is specified in absolute mode, regardless of
    whether this pitch is explicitly given as reference pitch or is
    found inside of the relative music.

> I'm still not sure that I would use it, and as a result I really don't
> like the "let's change it with convert-ly" idea.

Yes, that one is contentious.  I would like to convert the whole of the
LilyPond code base, and it would also be appropriate for independently
maintained content like Mutopia, but apart from the necessary change of
\relative { ... } to \relative c' { ... }, converting user documents
that are written and still maintained by the user himself is not really
nice.  But "this is the new recommended way, but if you want to use it
on old documents, you better rewrite all of them manually" is also
undesirable.

Should we mark optional conversions in convert-ly somehow and make it
possible to get them only when forced?  update-with-convert-ly, since it
is intended for our own use, would always force optional conversions.

> Actually, while I haven't used convert-ly so don't know how
> intelligent and aggressive it is in changing things,

convert-ly works by text manipulation in Python.  So each conversion
rule has to be judged by itself on those criteria.

The \relative rule is unusually intelligent, aggressive, and
conservative.

> it seems somewhat likely that such a change could break the score for
> Mars that I'm working on now.

Quite unlikely.  This conversion rule does not touch code it does not
understand.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]