On 17.02.2017 16:29, Urs Liska wrote:
Am 17.02.2017 um 09:21 schrieb David Kastrup:
Urs Liska <u...@openlilylib.org> writes:
Am 17.02.2017 um 08:34 schrieb d...@gnu.org:
Ok, I'll bite. What kind of piano music is written like
\score {
\new PianoStaff <<
\new Staff = "up" <<
\structure
\v.1
\v.2
>>
\dyn.1
\new Staff = "mid" <<
\structure
\v.3
\v.4
>>
\dyn.2
\new Staff = "lo" <<
\structure
\v.5
>>
>>
}
Because that is the example underlying your report.
Piano Music, at least starting with Liszt, all the way through into the
20th century and until today.
The Ravel piece here requires five individual voices that are basically
distributed among three staves (frequent staff changes included), but
are printed partially on a three-stave PianoStaff and partially using
only the standard two staves.
I feel it's natural to use PianoStaff here and to tell it to french
the middle system if empty.
PianoStaff is explicitly for the case where you want staves to be
frenched together. Its name does not mean "Piano inside" but rather
"Use frenching conventions common in piano music".
Then I'm tempted to file a bug report about PianoStaff being misnamed.
What else should the name PianoStaff imply than "Piano inside"? What you
are describing may be what developers have thought when inventing the
PianoStaff context, but for a user it is obvious that it refers to
"piano". Besides, "contexts explained" gives yet another explanation,
namely GrandStaff with support for grouped instrument names.
And you actually would still not want it to french out multiple staves
in an orchestral context: it should retain at least the two outer
voices.
Then PianoStaff should have a (so-far-nonexistent)
Remove_all_but_two_staves engraver by default.
I think the remove-layer concept is the best solution at hand (if,
indeed, we have it at hand?). I agree that PianoStaff should keep its
name and its definition be changed so it sensibly allows for more than
two staves, of which the extra ones may be removed.
Best, Simon
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
