On 2013/10/15 18:04:43, janek wrote:
Hi,
an afterthought.
On 2013/10/06 01:15:12, david.nalesnik wrote:
> The examples below represent my efforts to test the effects of
multiple
> applications of \offset. You can see that some accumulation is
possible.
> [...]
> %%%%
> \relative c' {
> %% TESTS FOR ACCUMULATION %%
>
> % default
> <c e g b>1\arpeggio
>
> \override Arpeggio.positions = #'(-3.5 . 0.5)
> <c e g b>1\arpeggio
>
> % values created by override are offset
> \offset #'positions #'(-2 . 2) Arpeggio
> <c e g b>1\arpeggio
I'm not sure if i haven't missed something, but to your realize that
in this
case the offset isn't applied on top of the override (as the comment
suggests),
but replaces it? This is self-evident in the example below:
\relative c' {
% default
<c e g b>1\arpeggio
\override Arpeggio.positions = #'(-5 . 5)
<c e g b>1\arpeggio
\offset #'positions #'(-1 . 2) Arpeggio
<c e g b>1\arpeggio
}
with current master (a82d8622e6b1be36169de7d2fe1f9aa88618933b,
containing offset
patch) the last arpeggio is shorter than the second, while it should
be longer
in both directions.
Well, that's the slightly icky thing. The \offset is with respect to
the situation you'll get when doing \revert Arpeggio.positions
afterwards. So if you want to make a _relative_ offset to the first
setting, you have to do
\temporary \offset #'positions #'(-1 . 2) Arpeggio
I'm not overly enthusiastic about how the \offset command ends up when
entered as an override. Maybe we should allow
\offset #'(-1 . 2) Arpeggio.positions here? It seems that the offset
list should not be confusable with a symbol? or whatever is used in the
front? So we could make that first argument optional, and complain when
the last argument is not a symbol list making up for it?
https://codereview.appspot.com/8647044/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
