<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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel