lilypond-user
[Top][All Lists]
Advanced

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

Re: \relative proposal: putting absolute pitches anywhere within \relati


From: nothingwavering
Subject: Re: \relative proposal: putting absolute pitches anywhere within \relative block using @-sign
Date: Thu, 14 Mar 2013 10:15:40 -0600

NEW IDEA

Thanks for the feedback, Mr. Kastrup and others.

The objections I hear from you and others on what I proposed are mainly these:

1. people not thrilled about their having (or other people having) to 
learn/use/implement a new syntax
2. objections to using up a new special symbol character for a function which 
is not entirely new



What if, instead of adding @-sign as new syntax, there were a way to use = sign 
for this cause?  Currently, it does exactly what I wish the @-sign would do, 
except that it also prints octave check warnings.  

I wouldn't change its default behavior, but perhaps if two == signs were used, 
then it could do the same as one equal sign, but not print a warning.  I don't 
think this would clash with existing = sign syntax and would not use up extra 
symbol characters.

Furthermore, the double equal sign could be used as either a requirement (or 
convention, but I like requiring it better) on the first note of a \relative { 
... } block to visually signify that the first note is specified absolutely.

Example:
        \relative { c==''4. b8 c g a b | c1 }

I want to require this syntax at the start of a relative block without a 
relative starting note before the brace, as a visual reminder that the first 
note is NOT relative to c' as has been the case up to now.  Using \relative and 
leaving off the reference pitch before the opening brace AND not specifying the 
first pitch after brace using a == sign should be an error.

I can't help but suspect that several long-time unsuspecting users in the habit 
of writing \relative { ... } and expecting the first note to be relative to c' 
will upgrade to a new version of lilypond or use someone else's machine with 
the newer version and write \relative { c ... } in a new project, expecting 
middle C to be printed and then be baffled at why LilyPond silent prints tenor 
C instead with no explanation.

I feel that the original proposal, as specified elsewhere, violates the 
principle of least surprise for existing users starting new projects (not using 
convert-ly) with the new LilyPond.

Thank you, Mr. Kastrup and everyone, for listening.

Good luck to the final decision makers, when the time comes, on making the 
right decision for LilyPond and its users.


--Christopher


On Mar 13, 2013, at 2:24 PM, David Kastrup <address@hidden> wrote:

> address@hidden writes:
> 
>> This is a breakaway thread from the one with the subject "Proposed new
>> available and recommended behavior of \relative"
> 
> I don't see what makes it "breakaway".
> 
>> I am *OPPOSED* to the proposal to change \relative syntax, as the
>> proposal now stands.  I think it is confusing to new users to have the
>> first pitch in a \relative block be absolute and the rest be relative.
> 
> Shrug.  Consider it relative to f, then.
> 
> Personally, I find
> \relative { g'' a b c } -> g'' a'' b'' c'''
> \relative { f'' a b c } -> f'' a'' b'' c'''
> more intuitive than the behavior you propose:
> \relative { g'' a b c } -> g'' a'' b'' c''' plus a warning
> \relative { f'' a b c } -> f''' a''' b''' c'''' plus a warning
> 
>> But I have another idea.  I'm not sure if people will like it right
>> away because it means changing/adding MORE syntax, but I think it will
>> be MORE useful and more *intuitive*!
> 
> More syntax is rarely more intuitive for writing since one would not
> think of it without prompting.  I don't consider it more intuitive for
> reading, either.
> 
>> Here's the idea.
>> 
>> 1. Define absolute octave syntax with the @-sign (let it be a mnemonic
>> for _A_bsolute) to be the syntax for temporarily specifying an
>> ABSOLUTE PITCH within a \relative block, such that the next pitch, if
>> it doesn't use the @-sign also, is relative to the absolute pitch.
> 
> We already have \resetRelativeOctave c'' for resetting the reference
> pitch to c''.  One could argue for a shorter name, if one considers it
> really important.
> 
>> 2. Keep \relative X { ... } working the same way as it is (DON'T make
>> convert-ly change it around).
> 
> There was no proposal to change the meaning of \relative X.  The changes
> from convert-ly were meant to make more use of the new \relative without
> X, but not for changing the meaning of \relative X.
> 
>> 3. Make \relative { X ... } work such the first pitch after the brace
>> is expected to be an absolute pitch syntax with the single equal sign.
> 
> Sounds like _another_ syntax not mentioned before.
> 
>> If it is not, a warning is printed and the pitch is interpreted as
>> relative to c' (the current behavior, except for the warning, right?).
> 
> No idea what you mean by "absolute pitch syntax with the single equal
> sign", in particular as you want to be interpreted relative to c' as
> "fallback" which does not appear to make any sense (have a fallback
> behave differently than what the check should be for?).
> 
>> Why a new syntax?  I frequently find that if I jump to the end of a
>> big, long \relative { ... }, then frequently I don't remember which
>> octave I'm in.
> 
> Welcome to \relative.
> 
>> Octave check is not a solution, because if I guess the part that comes
>> before the = sign wrong, I'll keep getting warnings until I fix it.
> 
> Welcome to \resetRelativeOctave.  Alternatively, just start a new
> \relative block inside of the existing one.  Its pitches will be
> independent from the outside ones, and the starting pitch is specified
> absolutely.
> 
>> What is wanted is a way to temporarily jump into absolute note entry
>> mode.
> 
> Welcome to \transpose c c { ... }.  Which we might call \absolute if
> people want that often enough.
> 
>> An @-sign comes immediately after the note name, and is followed by
>> any apostrophes or commas as necessary to specify the absolute octave.
>> 
>> Examples:
>> 
>> 1.   { c4 c' c@'' c@, }
> 
> That looks a lot like "Not invented here" syndrome to me.  You reject
> the existing mechanisms as well as proposals fitting with the current
> syntax in order to propose ones that purportedly do the same job without
> fitting in the existing framework.
> 
>> 3.   \relative { c@'4 c g' c }
>> 
>>      This is the same as { c'4 c' g' c'' } in absolute mode.  
>>      This would be the form that new users of LilyPond would be
>>      encouraged to use in the documentation.
> 
> And what would be c'@'4 ?  And how does it combine with octave checks?
> 
>> 4.   \relative { c4 c g' c }
>>      
>>      This is the same as 
>>              \relative c' { c4 c g' c }
>>      
>>      EXCEPT that a warning will be printed about encountering 
>>              \relative { X ... } 
>>      where X is not specified absolutely (with at-sign).
> 
> If you don't want the behavior used, just prohibit it and use convert-ly
> to get rid of existing usage.  That's issue 3231 currently on countdown.
> 
>> What do people think?
> 
> Not a winner to me.  I would not want to spend a potentially useful
> extension character like @ on something that does not appear to offer
> anything new.
> 
> Now you don't like the current proposal, and that's duly noted.
> Brainstorming is always exciting and makes one fond of one's own flashes
> of genius.  But I think that if you view this proposal realistically,
> you'll find that it has several badly defined aspects, it is not
> self-explanatory (of course neither is \relative { f'' }, but at least
> without any previous exposure to relative mode starting pitches, a
> result of f'' is a more likely guess to me than f'''), and it clutters
> the writing of pitches additionally.
> 
> It is also leads to inconsistencies: why write \relative c' { ... }
> instead of \relative c@' { ... }?  The argument to \relative is in
> absolute pitch!  Why indeed write \relative at all if the absence of @
> is supposed to be sufficient for indicating relative pitch on its own?
> 
> -- 
> David Kastrup




reply via email to

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