Paul Morris <[email protected]> writes:
>> On May 18, 2015, at 5:13 AM, Joram <[email protected]> wrote:
>>
>> shifting the octave is *not* absolute. So the input
>> \absolute c'' { c' } for c''' is a contradiction in itself.
>> That’s why I strongly recommend not to use \absolute for some kind of
>> non-absolute notation.
>
> +1, and especially with new users in mind.
>
> I agree with David that two commands are better than three here, and
> so I think replacing \absolute with the new \fixed is the best
> solution (scheme “d” in David’s list).
>
> In terms of assessing trade-offs I’d be willing to help document
> \fixed (as the new \absolute) if that is a significant factor. I
> think it would be worth the effort. \fixed could well become the
> generally preferred entry mode. \absolute hasn’t been around that
> long (2.18 was the first stable that had it), and its use case is
> probably not all that common (I think people tend to prefer either
> relative or absolute entry and not use both). The convert-ly rule
> would be easy.
>
> If we can’t come to a consensus I’m not opposed to taking this to a
> user list discussion and vote. In the interest of focusing that
> effort, at this point is anyone advocating for “\octave”?
It makes some sense for a split scheme retaining \absolute and with
\octave having a non-optional argument:
\absolute { c'' g' }
\octave c'' { c g, }
It becomes unreadable with optional argument left off:
\octave { c'' g' }
\octave c'' { c g, }
We've had people complain that they'd like do see \absolute '' or
\absolute x'' rather than \absolute c'' because they don't like to see a
notename involved in the reference.
\octave c'' presumably will stress that just the octave of the reference
pitch is taken.
So I think there is a case for \relative/\absolute/\octave pitted
against \relative/\absolute/\absolute and \relative/\fixed/\fixed. It
is backwards compatible and more descriptive than the alternatives as
long as its pitch argument is mandatory.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
