lilypond-auto
[Top][All Lists]
Advanced

[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



reply via email to

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