Re: NR: Document \remove "Keep_alive_together_engraver" (issue 318580043 by g...@ursliska.de)

2017-02-16 Thread Urs Liska 


Am 17.02.2017 um 08:34 schrieb d...@gnu.org:
> On 2017/02/17 07:27:27, git wrote:
>> On 2017/02/17 07:24:42, dak wrote:
>
>> > Documentation should not focus about how to use the wrong tool for
> the job.
>> > If you want to document it, do it the other way round: explain how
> you can keep
>> > the staves of a GrandStaff together and then mention that this
> behavior is desired
>> > so often for piano that PianoStaff is already separately available.
>
>> I don't see how PianoStaff is the wrong tool to notate piano music.
>
>> But I will see to rewriting it the other way round.
>
> 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.
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.

___
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)

2017-02-16 Thread dak 

On 2017/02/17 07:27:27, git wrote:

On 2017/02/17 07:24:42, dak wrote:



> Documentation should not focus about how to use the wrong tool for

the job.

> If you want to document it, do it the other way round: explain how

you can keep

> the staves of a GrandStaff together and then mention that this

behavior is desired

> so often for piano that PianoStaff is already separately available.



I don't see how PianoStaff is the wrong tool to notate piano music.



But I will see to rewriting it the other way round.


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.

https://codereview.appspot.com/318580043/

___
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)

2017-02-16 Thread git 

On 2017/02/17 07:24:42, dak wrote:

https://codereview.appspot.com/318580043/diff/1/Documentation/notation/staff.itely

File Documentation/notation/staff.itely (right):



https://codereview.appspot.com/318580043/diff/1/Documentation/notation/staff.itely#newcode793

Documentation/notation/staff.itely:793: removed from the

@code{PianoStaff}

context to allow individual staves to
Sorry, but that makes no sense.  Use GrandStaff instead of PianoStaff

if you

don't want a PianoStaff.



Documentation should not focus about how to use the wrong tool for the

job.  If

you want to document it, do it the other way round: explain how you

can keep the

staves of a GrandStaff together and then mention that this behavior is

desired

so often for piano that PianoStaff is already separately available.


I don't see how PianoStaff is the wrong tool to notate piano music.

But I will see to rewriting it the other way round.

https://codereview.appspot.com/318580043/

___
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)

2017-02-16 Thread dak 


https://codereview.appspot.com/318580043/diff/1/Documentation/notation/staff.itely
File Documentation/notation/staff.itely (right):

https://codereview.appspot.com/318580043/diff/1/Documentation/notation/staff.itely#newcode793
Documentation/notation/staff.itely:793: removed from the
@code{PianoStaff} context to allow individual staves to
Sorry, but that makes no sense.  Use GrandStaff instead of PianoStaff if
you don't want a PianoStaff.

Documentation should not focus about how to use the wrong tool for the
job.  If you want to document it, do it the other way round: explain how
you can keep the staves of a GrandStaff together and then mention that
this behavior is desired so often for piano that PianoStaff is already
separately available.

https://codereview.appspot.com/318580043/

___
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)

2017-02-16 Thread git 

Reviewers: lemzwerg,

Message:
On 2017/02/17 05:38:44, lemzwerg wrote:

...

Please use two spaces after a full stop that closes a sentence.

Sorry, missed that one. Fixed but without new patch set.



Description:
NR: Document \remove "Keep_alive_together_engraver"

Please review this at https://codereview.appspot.com/318580043/

Affected files (+43, -1 lines):
  M Documentation/notation/staff.itely


Index: Documentation/notation/staff.itely
diff --git a/Documentation/notation/staff.itely  
b/Documentation/notation/staff.itely
index  
d7ed3e6738b55b9cb8ac7bbc3cc496625c8d0eaf..1526ce18b5f288c1d91f713d999d2d69b37bd3f3  
100644

--- a/Documentation/notation/staff.itely
+++ b/Documentation/notation/staff.itely
@@ -785,6 +785,49 @@ elements.}
 >>
 @end lilypond

+By default any empty staff can be frenched, but sometimes staff groups
+are linked and should only be hidden together when @emph{all} staves are
+empty at the same time. This behaviour is the default for @code{PianoStaff}
+where empty staves are usually continued.  The
+@code{Keep_alive_together_engraver} which is responsible for this can be
+removed from the @code{PianoStaff} context to allow individual staves to
+be frenched.  This is for example useful in complex piano music that
+features sections with two or more staves.
+
+@lilypond[verbatim,quote,ragged-right]
+\layout {
+  \context {
+\Staff
+\RemoveEmptyStaves
+  }
+  \context {
+\PianoStaff
+\remove "Keep_alive_together_engraver"
+  }
+}
+
+\relative <<
+  \new PianoStaff <<
+\new Staff {
+  e'4 f g a \break
+  b1 \break
+  a4 b c2
+}
+\new Staff {
+  c,4 d e f \break
+  R1 \break
+  f4 g c,2
+}
+\new Staff {
+  \clef bass
+  c,4 d e f \break
+  g1 \break
+  f4 g c,2
+}
+  >>
+>>
+@end lilypond
+
 @cindex ossia

 @noindent
@@ -1507,4 +1550,3 @@ between @code{Voice} and @code{CueVoice} contexts.   
When using

 @code{\cueDuringWithClef} or @code{\transposedCueDuring} the extra
 argument required for each case must come after the quote and the
 direction.
-



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

NR: Document \remove "Keep_alive_together_engraver" (issue 318580043 by g...@ursliska.de)

2017-02-16 Thread lemzwerg 

LGTM


https://codereview.appspot.com/318580043/diff/1/Documentation/notation/staff.itely
File Documentation/notation/staff.itely (right):

https://codereview.appspot.com/318580043/diff/1/Documentation/notation/staff.itely#newcode790
Documentation/notation/staff.itely:790: empty at the same time. This
behaviour is the default for @code{PianoStaff}
Please use two spaces after a full stop that closes a sentence.

https://codereview.appspot.com/318580043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Web: examples page: move more common use cases higher in the list (issue 318560043 by paulwmor...@gmail.com)

2017-02-16 Thread paulwmorris 

Reviewers: ,

Message:
Finally got around to this.  -Paul

Description:
Web: examples page: move more common use cases higher in the list

Makes the order match the list on the home page.
Also adds an additional line between the code for each example for
better readability.

Please review this at https://codereview.appspot.com/318560043/

Affected files (+39, -28 lines):
  M Documentation/web/introduction.itexi


Index: Documentation/web/introduction.itexi
diff --git a/Documentation/web/introduction.itexi  
b/Documentation/web/introduction.itexi
index  
a3bde1bf941c20acda44a2edf049ab14c27f001b..4327edde1e3257bd2959345e917d387e1bba4849  
100644

--- a/Documentation/web/introduction.itexi
+++ b/Documentation/web/introduction.itexi
@@ -302,7 +302,6 @@ already decided to try LilyPond, first read about our
 @unnumberedsec Examples

 @divClass{column-center-top}
-
 @subheading Beautiful Examples

 LilyPond is a powerful and flexible tool for engraving tasks of
@@ -310,6 +309,7 @@ all kinds.  Please browse our gallery of examples and  
be inspired!


 @divEnd

+
 @divClass{column-center-middle-color2}
 @subheading Classical Music

@@ -319,6 +319,7 @@ in LilyPond.
 @exampleImage{bach-bwv610}
 @divEnd

+
 @divClass{column-center-middle-color2}
 @subheading Complex Notation

@@ -329,6 +330,7 @@ beams, cross-staff stems, and voice-follow lines.
 @exampleImage{granados}
 @divEnd

+
 @divClass{column-center-middle-color2}
 @subheading Early Music

@@ -338,6 +340,7 @@ as this passage of Gregorian chant.
 @exampleImage{ancient-headword}
 @divEnd

+
 @divClass{column-center-middle-color2}
 @subheading Modern Music

@@ -365,6 +368,7 @@ full score, piano-vocal reduction, and a violin part.

 @divEnd

+
 @divClass{column-center-middle-color2}
 @subheading Tablature

@@ -376,25 +380,6 @@ staff.
 @exampleImage{tab-example}
 @divEnd

-@divClass{column-center-middle-color2}
-@subheading Schenker Graphs
-
-Standard output can be modified heavily.  Here is an impressive
-Schenkerian analysis, created by Kris Schaffer, for an article
-in @uref{http://www.linuxjournal.com/article/8364 , Linux Journal}.
-The colors have been added for better visibility.
-
-@exampleImage{bach-schenker}
-@divEnd
-
-@divClass{column-center-middle-color2}
-@subheading Customized Output
-
-A short excerpt from Stockhausen's Klavierstück II to demonstrate
-LilyPond's ability to provide customised output.
-
-@exampleImage{Stockhausen_Klavierstueck2}
-@divEnd

 @divClass{column-center-middle-color2}
 @subheading Vocal Music
@@ -410,14 +395,6 @@ and the ligature braces above certain groups of notes.
 @exampleImage{aucun-snippet}
 @divEnd

-@divClass{column-center-middle-color2}
-@subheading Educational Applications
-
-LilyPond is perfectly suited for educational purposes as well.
-Here is an example of a simple counterpoint exercise.
-
-@exampleImage{theory}
-@divEnd

 @divClass{column-center-middle-color2}
 @subheading Lead Sheets
@@ -430,6 +407,17 @@ to suit nearly any situation.
 @exampleImage{chart}
 @divEnd

+
+@divClass{column-center-middle-color2}
+@subheading Educational Applications
+
+LilyPond is perfectly suited for educational purposes as well.
+Here is an example of a simple counterpoint exercise.
+
+@exampleImage{theory}
+@divEnd
+
+
 @divClass{column-center-middle-color2}
 @subheading Large Projects

@@ -441,6 +429,29 @@ contributed by Hu Haipeng, a blind composer.
 @exampleImage{orchestra}
 @divEnd

+
+@divClass{column-center-middle-color2}
+@subheading Customized Output
+
+A short excerpt from Stockhausen's Klavierstück II to demonstrate
+LilyPond's ability to provide customised output.
+
+@exampleImage{Stockhausen_Klavierstueck2}
+@divEnd
+
+
+@divClass{column-center-middle-color2}
+@subheading Schenker Graphs
+
+Standard output can be modified heavily.  Here is an impressive
+Schenkerian analysis, created by Kris Schaffer, for an article
+in @uref{http://www.linuxjournal.com/article/8364 , Linux Journal}.
+The colors have been added for better visibility.
+
+@exampleImage{bach-schenker}
+@divEnd
+
+
 @divClass{column-center-bottom}
 @subheading Where now?



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Automatic LyricExtenders (issue 313240043 by perpeduumimmob...@gmail.com)

2017-02-16 Thread dak 


https://codereview.appspot.com/313240043/diff/21/lily/lyric-extender.cc
File lily/lyric-extender.cc (right):

https://codereview.appspot.com/313240043/diff/21/lily/lyric-extender.cc#newcode63
lily/lyric-extender.cc:63: while (hs && robust_scm2double
(heads[hs-1]->get_property
On 2017/02/06 19:08:18, dak wrote:

Same as previously I see.


Which begs the question: what are the exact rules governing grace notes?
 Wouldn't it be sufficient to not even add any grace note to the "heads"
array?  Because at the time we add stuff there, the grace time of the
time step is still perfectly available.  Or are there situations where a
grace note should be present in "heads"?

https://codereview.appspot.com/313240043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel