<dak <at> gnu.org> writes:
> On 2014/10/31 22:50:35, Dan Eble wrote:
>
> > One thing just occurred to me. If this option is going into the UI,
> do you
> > think the numbers should be 1-based for easier comprehension by
> musicians?
> As a UI, numbers instead of intervals (possibly represented only by a
> pitch in relation to c' like \transposition does) do not make much
> sense.
I may be having trouble with the negative sentence construction, but
if you mean that
\partcombine <d' c''> {} {}
would be the intuitive way to indicate seconds through octave may be
be combined into chords, then I disagree. Or, maybe you were joking.
Numbers are very good for representing intervals; we use numerical
names to represent them. Numbers are also good for representing
differences in staff-position as well. Either 1-based or 0-based
should be fine, if the docs consistently speak in terms of intervals
of the chords, or in terms of the graphical separation between noteheads,
respectively.
> Regarding such user interface extensions, I think we should rather go in
> the direction of
> <URL:https://code.google.com/p/lilypond/issues/detail?id=1321#c30>.
> Using context modifications makes it reasonably straightforward to add
> arbitrary named settings in arbitrary order on demand.
Well, the currently-proposed patch at your link uses optional
arguments to \partcombine, which would also be appropriate here
for the chord-range, and later for 'no-solo. If that is the
direction you mean, we all agree: optional input argument #'(2 . 8)
If you mean to use context properties, they cannot be context
properties of the output Voices because those are not created when
the chord-range needs to have its effect. they cannot be
properties of the temporary Voices for the same reasons that idea
failed for the interface to force part-combine decisions.
Generally issue 1321 concerns how the voices output from partcombine
are set on the staff, so it should not change the input interface to
partcombine at all.
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
