Re: NR: Document \remove "Keep_alive_together_engraver" (issue 318580043 by g...@ursliska.de)
Urs Liska 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". 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. So one solution might be to remove the middle stave from the Keep_alive_together_engraver's scope, with a proper setting of, uh, VerticalAxisGroup.remove-layer ? I'm a bit fuzzy on our current state in that area. > What I think I'll write to the docs now is that you have the choice > between resorting to GrandStaff (for the piano) or to remove the > engraver. There really is no point to removing an engraver when the sole purpose of PianoStaff is to add it. Our documentation should focus more on keeping people on top of LilyPond rather than teaching them how to stumble along when they have no clue. Because there are a whole lot of ways to do that and if we wanted to document all of them... I mean, we have the discussion lists for that. Ask one question, get 10 answers. But we don't have the room for 10 answers in the documentation, so we should pick the best one. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR: Document \remove "Keep_alive_together_engraver" (issue 318580043 by g...@ursliska.de)
On 17.02.2017 09:21, David Kastrup wrote: 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". 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. So one solution might be to remove the middle stave from the Keep_alive_together_engraver's scope, with a proper setting of, uh, VerticalAxisGroup.remove-layer ? +1 Best, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR: Document \remove "Keep_alive_together_engraver" (issue 318580043 by g...@ursliska.de)
Am 17.02.2017 um 09:21 schrieb David Kastrup: > Urs Liska 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 . > > So one solution might be to remove the middle stave from the > Keep_alive_together_engraver's scope, with a proper setting of, uh, > VerticalAxisGroup.remove-layer ? > > I'm a bit fuzzy on our current state in that area. > >> What I think I'll write to the docs now is that you have the choice >> between resorting to GrandStaff (for the piano) or to remove the >> engraver. > There really is no point to removing an engraver when the sole purpose > of PianoStaff is to add it. This is obviously a developer-centric way to see it. From any user's perspective the primary purpose of PianoStaff is to enclose piano music in it. > Our documentation should focus more on > keeping people on top of LilyPond rather than teaching them how to > stumble along when they have no clue. Because there are a whole lot of > ways to do that and if we wanted to document all of them... Well, so far no suitable way to create slightly extended (but common since about 1830) piano notation has been documented. The obvious solution (\RemoveEmptyStaves) doesn't work, and the suggestion to use GrandStaff because PianoStaff is not actually meant for piano music is, well, strange. > I mean, we have the discussion lists for that. Ask one question, get > 10 answers. But we don't have the room for 10 answers in the > documentation, so we should pick the best one. > -- u...@openlilylib.org https://openlilylib.org http://lilypondblog.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR: Document \remove "Keep_alive_together_engraver" (issue 318580043 by g...@ursliska.de)
On 17.02.2017 16:29, Urs Liska wrote: Am 17.02.2017 um 09:21 schrieb David Kastrup: Urs Liska 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
Re: NR: Document \remove "Keep_alive_together_engraver" (issue 318580043 by g...@ursliska.de)
Urs Liska writes: > Am 17.02.2017 um 09:21 schrieb David Kastrup: >> Urs Liska 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. Well, you can write bass notes in a treble clef and vice versa and tenors rarely use a tenor clef. > What else should the name PianoStaff imply than "Piano inside"? A staff for the conventions typical for piano. Lyrics contexts are used for more than lyrics, and the ChordNames context is unsuitable for the chord placement conventions of accordion. If you are writing a chant for choir, you are unlikely to use a ChoirStaff. > 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. Well, you might want to fix _that_ piece of documentation. GrandStaff and PianoStaff are totally equivalent in that regard. I am not quite sure since when. commit 8656e359d629aed6990bb8d8d3da8eac2d2c311e Author: Reinhold Kainhofer Date: Tue Jan 25 17:59:02 2011 +0100 Add the Instrument_name_engraver also to all group contexts Also, make sure it is not inherited from the parent (in particular in nested staff groups). looks like it might be related. >> 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 don't really think that we should let the context names overdetermine the semantics in hard-to-understand, hard-to-explain and hard-to-override manners. Contexts are building blocks for a score. We should document how to use them to best advantage and how to use them as the basis for more complex tasks. But they are really not supposed to outsmart the user. >> So one solution might be to remove the middle stave from the >> Keep_alive_together_engraver's scope, with a proper setting of, uh, >> VerticalAxisGroup.remove-layer ? >> >> I'm a bit fuzzy on our current state in that area. >> >>> What I think I'll write to the docs now is that you have the choice >>> between resorting to GrandStaff (for the piano) or to remove the >>> engraver. >> There really is no point to removing an engraver when the sole purpose >> of PianoStaff is to add it. > > This is obviously a developer-centric way to see it. From any user's > perspective the primary purpose of PianoStaff is to enclose piano > music in it. We cannot foresee and foreplan every use case that a user may want. We don't have an "OrganStaff" either: there is just too much variety in the notation there and possibly desired Frenching. For piano music, a two-staff container without independently frenched voices is typical. Non-bottom Contexts are _containers_ that always start out empty and have to be filled by the user. We don't have control about what the user might want to fill in here. If we wanted this control, we would need all of \PianoTrebleStaff, \PianoBassStaff, \PianoOptionalStaff contexts and tell the user to fill only those into a PianoStaff. If we wanted to be obnoxious about it, we would \denies every other staff context type. There might be some incentive for a specific piano music style file to do it in this manner. But as core LilyPond functionality, it seems out of place. >> Our documentation should focus more on keeping people on top of >> LilyPond rather than teaching them how to stumble along when they >> have no clue. Because there are a whole lot of ways to do that and >> if we wanted to document all of them... > > Well, so far no suitabl
PATCHES - Countdown for February 17th
Hello, Here is the current patch countdown list. The next countdown will be on February 20th A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: 5044 Bug in german documentation - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5044 http://codereview.appspot.com/314460043 Countdown: 5071 Documenting 5067 (ly:version?) - Urs Liska https://sourceforge.net/p/testlilyissues/issues/5071 http://codereview.appspot.com/317270043 5070 Use explicit typecasts for Scm_variable->SCM - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5070 http://codereview.appspot.com/316300043 5069 Avoid using void * as SCM - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5069 http://codereview.appspot.com/314500043 5068 SCM/bool confusion in One_page_breaking::solve - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5068 http://codereview.appspot.com/314490043 5067 Add lilypond version predicates/operators - Urs Liska https://sourceforge.net/p/testlilyissues/issues/5067 http://codereview.appspot.com/317270043 5064 Let analysis brackets support text - Thomas Morley https://sourceforge.net/p/testlilyissues/issues/5064 http://codereview.appspot.com/315570043 Review: 5072 Web: examples page: move more common use cases higher in the list - Paul Morris https://sourceforge.net/p/testlilyissues/issues/5072 http://codereview.appspot.com/318560043 New: No new patches at this time. Waiting: 4600 Let notes/rests suppress multi-measure rest grobs - Dan Eble https://sourceforge.net/p/testlilyissues/issues/4600 http://codereview.appspot.com/265160043 Regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel