[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lilypond-auto] Issue 4338 in lilypond: Octavecheck - unexpected beh
From: |
lilypond |
Subject: |
Re: [Lilypond-auto] Issue 4338 in lilypond: Octavecheck - unexpected behavior |
Date: |
Tue, 07 Apr 2015 14:32:24 +0000 |
Comment #1 on issue 4338 by address@hidden: Octavecheck - unexpected behavior
https://code.google.com/p/lilypond/issues/detail?id=4338
Looking at the code in lily/relative-octave-check.cc I find that a valid
check will return the last encountered pitch (thus being transparent) while
an invalid check will instead leave "last pitch" at the value that would
have passed the respective octave check while retaining all pitch
components except for the octave.
So yes, this would agree with the "guess what happens" rather than our
current documentation.
Grepping over Mutopia, there is a considerable number of such checks
(though probably mainly by a single author).
The documented behavior would be inconsistent since it is quite clear that
the notion of "last pitch" is not changed when everything checks out. So
there would not be a point in changing anything but the octave of "last
pitch" when it doesn't.
While changing the behavior in the case of an error should have few
repercussions (all finalized music documents are expected to pass their
octave checks), the loss in consistency to a passing check would appear
like a bad idea. So I'd vote for just adapting the documentation to state
that the octave of LilyPond's "last pitch" notion is changed such that it
would pass the relative octave check.
As to the = syntax: I don't really like it since it gets confusingly
similar to assignments particularly when we are talking about pitches not
needing any octave marker. Unsurprisingly this also makes it a frequent
source of headaches when working on LilyPond's grammar.
The main advantage of this syntax is that the "what happens when octave
check and last pitch have a different notename or accidental" question does
not come up.
The main disadvantage apart from the syntactic likeness to assignments is
that several users opined in discussions surrounding use of \relative that
the _only_ notename for which they comfortably know the right octave number
is c and they count off everything from there.
\octaveCheck can serve those users, while the = octave checks won't do the
trick for them as their reference notename is not c but rather that of the
checked note.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings