Re: Best practice for parts with varying number of staves

[Janek Warchoł]

Hi Kieren,

2014-08-28 1:43 GMT+02:00 Kieren MacMillan :
> Hi Janek,
>
>> What's the status of your "partcombining framework”?
>
> It stalled last year, usurped by a constant stream of paid commissions.
>
> However, my father-in-law has generously offered to sponsor me to take a few 
> weeks
> and finally engrave that big choral piece I mentioned (which would benefit 
> spectacularly
> from really good unison/divisi machinery). I could take that two weeks 
> sometime in late
> September or early October, if that’s good timing for you.

By October we should (hopefully) be more or less done with our project
- but you never know...
Anyway, I've started working on this now - feel invited to join!
Could you send me your drafts?  (btw, you don't have to tidy them
before sending, i know how it's like to stop working on something
midway :))

best,
Janek

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

Re: brainstorming a really smart system engraver

[Janek Warchoł]

Hi,

2014-08-28 1:40 GMT+02:00 Kieren MacMillan :
> Hi all,
>
>>> I think that issue 3518 (pushed recently) does just this:
>>> https://code.google.com/p/lilypond/issues/detail?id=3518
>>
>> It doesn't do the automatic "AI nightmare" part.
>
> Yes, unfortunately...

Yes, sorry - i should've trimmed quoted email better.

>> However, it provides the low level machinery for pulling in the "maximally 
>> required" number
>> of staves between automatic or manual line breaks, where the requirement
>> is determined by working with keep-alive-interfaces and tags on the
>> various staff variants.
>
> That could be helpful!
>
> I still need to wrap my head around how this framework/machinery works (or 
> doesn’t) with
> true content-presentation separation; the example on the Google Code page has 
> multiple
> "\context Staff” calls buried in the \violins note definition, which to my 
> mind mixes content
> with presentation in an unfortunate way.

I think you looked at an earlier work-in-progress snippet -  in the
attachment you can find the "final" version.  Instead of having music
jump between staves, it typesets everything in two variants (divided
and not) and specifies what should be visible at which times.  Seems
to be the right way to separate content and presentation.

>> It's a solid framework for a solid part of the job.
>
> I’ll be interested in my testing to see what percentage of real-world 
> scenarios this part represents.
>
>> The important thing to note is that this framework does _not_ require
>> manual tampering with line breaks to arrive at "correct" results.
>
> That is a critical and wonderful feature.

Indeed!
best,
Janek
\version "2.19.13"

\header {
  texidoc = "The @code{VerticalAxisGroup.remove-layer}
property can be used for typesetting temporary divisi staves where
the switch to split staves is done only at line breaks such that all
complex passages are rendered in separate staves."
}

boring = \set Staff.keepAliveInterfaces = #'()
tricky = \unset Staff.keepAliveInterfaces

violI=\relative d' {
  \boring \repeat unfold 100 d4
  \tricky 2
  \boring \repeat unfold 98 d4
  \bar "|."
}

violII=\relative g {
  \boring \repeat unfold 100 g4
  \tricky 2
  \boring \repeat unfold 98 g4
  \bar "|."
}

\score {
  \new StaffGroup \with { \consists "Keep_alive_together_engraver" }
  <<
\new Staff \with { instrumentName = "Violin I"
		   shortInstrumentName = "V I"
		   \override VerticalAxisGroup.remove-empty = ##t
		   \override VerticalAxisGroup.remove-first = ##t
		   \override VerticalAxisGroup.remove-layer = 1
		 }
\violI
\new Staff \with { instrumentName = "Violin II"
		   shortInstrumentName = "V II"
		   \override VerticalAxisGroup.remove-empty = ##t
		   \override VerticalAxisGroup.remove-first = ##t
		   \override VerticalAxisGroup.remove-layer = 1
		 }
\violII
\new Staff \with { instrumentName = "Violins"
		   shortInstrumentName = "V I&II"
		   \override VerticalAxisGroup.remove-layer = 2
		 }
<<  \violI \\ \violII  >>
  >>
  \layout {
short-indent = 2\cm
indent = 3\cm
  }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Modifying barline right before a stave is hidden

[Janek Warchoł]

Hi all,

is it possible to write a function that does something based on
whether the current context will be visible or hidden in the next
system?  For example, i have

\version "2.19.12"

\layout {
  \context {
\Score
\RemoveEmptyStaves
  }
}

fooBarline = {}

<<
  \new Staff {
\fooBarline
\repeat unfold 24 c'4
R1*8
  }
  \new Staff {
\repeat unfold 24 f'2
  }
>>

And i'd like to define fooBarline so that the last barline before the
staff is hidden (which happens because of RemoveEmptyStaves) is
different.

best,
Janek

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

Re: Modifying barline right before a stave is hidden

[David Kastrup]

Janek Warchoł  writes:

> Hi all,
>
> is it possible to write a function that does something based on
> whether the current context will be visible or hidden in the next
> system?  For example, i have
>
> \version "2.19.12"
>
> \layout {
>   \context {
> \Score
> \RemoveEmptyStaves
>   }
> }

No, and your question does not even make sense.  There is no "current
context" by the time \RemoveEmptyStaves has an effect.  Iteration is
over, and arranging the bunch of grobs it produced is already in a late
stage of assembly, after determining line breaks.  Any connection to a
context is confined to the properties a Grob inherited from the
engraver's context's properties at the time it was created.

\RemoveEmptyStaves has resulted in the creation of VerticalAxisGroup
grobs with suicidal tendencies.  They commit suicide based on the live
and death of other potentially suicidal VerticalAxisGroup grobs, and
based on whether they have seen grobs created (and survive) supporting
any of a number of specified interfaces during their lifetime.

-- 
David Kastrup

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

Re: brainstorming a really smart system engraver

[David Kastrup]

Janek Warchoł  writes:

> 2014-08-28 1:40 GMT+02:00 Kieren MacMillan :
>> Hi all,
>>
 I think that issue 3518 (pushed recently) does just this:
 https://code.google.com/p/lilypond/issues/detail?id=3518
>>>
>>> It doesn't do the automatic "AI nightmare" part.
>>
>> Yes, unfortunately...
>
> Yes, sorry - i should've trimmed quoted email better.
>
>>> However, it provides the low level machinery for pulling in the
>>> "maximally required" number
>>> of staves between automatic or manual line breaks, where the requirement
>>> is determined by working with keep-alive-interfaces and tags on the
>>> various staff variants.
>>
>> That could be helpful!
>>
>> I still need to wrap my head around how this framework/machinery
>> works (or doesn’t) with
>> true content-presentation separation; the example on the Google Code
>> page has multiple
>> "\context Staff” calls buried in the \violins note definition, which
>> to my mind mixes content
>> with presentation in an unfortunate way.
>
> I think you looked at an earlier work-in-progress snippet -  in the
> attachment you can find the "final" version.

Which is still oversimplified: this is a regtest possibly pretending to
be too much.  The main problem with the regtest is that it typesets
everything in two versions whereas a "proper" version should replace the
single-staff variant with skips while the double-staff variant is known
to win: it's not just saving unnecessary processing time, but there is
no point in letting the larger horizontal space requirements of the
single-staff variant determine line breaks in passages where the
single-staff variant is known to be irrelevant.

That's why I pointed to the different unisono/divisi issue's attachment
which does a more thorough job.

-- 
David Kastrup

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

Re: brainstorming a really smart system engraver

[David Kastrup]

Kieren MacMillan  writes:

> Hi all,
>
>>> I think that issue 3518 (pushed recently) does just this:
>>> https://code.google.com/p/lilypond/issues/detail?id=3518
>> 
>> It doesn't do the automatic "AI nightmare" part.
>
> Yes, unfortunately...
>
>> However, it provides the low level machinery for pulling in the
>> "maximally required" number
>> of staves between automatic or manual line breaks, where the requirement
>> is determined by working with keep-alive-interfaces and tags on the
>> various staff variants.
>
> That could be helpful!
>
> I still need to wrap my head around how this framework/machinery works
> (or doesn’t) with true content-presentation separation; the example on
> the Google Code page has multiple "\context Staff” calls buried in the
> \violins note definition, which to my mind mixes content with
> presentation in an unfortunate way.

The example attached to the last comment of the related issue
https://code.google.com/p/lilypond/issues/detail?id=2779> goes a
bit further towards creating an ad-hoc interface rather than just
pulling the low-level levers.

-- 
David Kastrup

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

Re: brainstorming a really smart system engraver

[Kieren MacMillan]

Hi all,

> The example attached to the last comment of the related issue
> https://code.google.com/p/lilypond/issues/detail?id=2779> goes a
> bit further towards creating an ad-hoc interface rather than just
> pulling the low-level levers.

Thanks! This looks very good in the code… but I’ll have to wait for a binary to 
see how the output looks/works and really stress-test the feature, since i’m 
still on v2.19.12 at the moment.

Best,
Kieren.

___

Kieren MacMillan, composer
www:  
email:  i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

partcombine/divisi framework - let the fun begin!

[Janek Warchoł]

Hi all,

I'm working on putting together a set of functions for handling parts
that split into multiple voices and/or staves (using functionality
David Kastrup implemented in
https://code.google.com/p/lilypond/issues/detail?id=3518).  I attach a
first version and i'd be interested in your comments.

best,
Janek
\version "2.19.13"

together = { \tag #'together <>^\markup \bold "a2" }

soloI =
#(define-music-function (parser location mus) (ly:music?)
   #{
 <<
   \tag #'together <>^\markup \bold SoloI
   \tag #'divI { #mus }
   \tag #'together { #mus }
   \tag #'divII #(mmrest-of-length mus)
 >>
   #})

sharedStems =
#(define-music-function (parser location m1 m2) (ly:music? ly:music?)
   #{
 <<
   \tag divI  { #m1 }
   \tag divII { #m2 }
   \tag together <>^\markup \bold "div"
   \tag together << #m1 #m2 >>
 >>
   #})

voiceDivisi =
#(define-music-function (parser location m1 m2) (ly:music? ly:music?)
   #{
 <<
   \tag divI  { #m1 }
   \tag divII { #m2 }
   \tag together << { \dynamicUp #m1 } \\ { \dynamicDown #m2 } >>
 >>
   #})

staffDivisi =
#(define-music-function (parser location m1 m2) (ly:music? ly:music?)
   #{
 \unset Staff.keepAliveInterfaces
 <<
   \tag divI  { #m1 }
   \tag divII { #m2 }
   \tag together #(skip-of-length m1)
   \tag together #(skip-of-length m2)
 >>
 \set Staff.keepAliveInterfaces = #'()
   #})

divisibleStaff =
#(define-music-function (parser location name music) (string? ly:music?)
   (let ((nameI (string-append name " I"))
 (nameII (string-append name " II")))
 #{
   \new GrandStaff \with {
 \consists "Keep_alive_together_engraver"
   } <<
 \new Staff \with {
   \override VerticalAxisGroup.remove-first = ##t
   \override VerticalAxisGroup.remove-empty = ##t
   \override VerticalAxisGroup.remove-layer = 1
   keepAliveInterfaces = #'()
   instrumentName = #nameI
   shortInstrumentName = #nameI
 }
 \keepWithTag divI \music

 \new Staff \with {
   \override VerticalAxisGroup.remove-first = ##t
   \override VerticalAxisGroup.remove-empty = ##t
   \override VerticalAxisGroup.remove-layer = 1
   keepAliveInterfaces = #'()
   instrumentName = #nameII
   shortInstrumentName = #nameII
 }
 \keepWithTag divII \music

 \new Staff \with {
   instrumentName = #name
   shortInstrumentName = #name
   \override VerticalAxisGroup.remove-layer = 2
 }
 \keepWithTag together \music
   >>
 #}))
\version "2.19.13"

\include "definitions.ily"

\layout {
  short-indent = 2\cm
  indent = 2\cm
  line-width = 10\cm
}

music = {
  \together
  c'4 d' e' f'
  \sharedStems
  { a' f' a' g' }
  { f' d' f' e' }
  \voiceDivisi {
g' b' d' b'
d'' b' g' b'
  }
  {
g'4 e' g' e'
b' g' b' g'
  }
  \staffDivisi
  {  g' q b' }
  { a'  a' q }
  \together
  c' d' e' f'
  \soloI { g' b' d' b' }
  \together
 
  f' e' d' c'
}

\markup \bold { Violin I part: }
\new Staff \with {
  instrumentName = "Violin I"
  shortInstrumentName = "V I"
} \keepWithTag divI \music

\markup \bold { Violin II part: }
\new Staff \with {
  instrumentName = "Violin II"
  shortInstrumentName = "V II"
} \keepWithTag divII \music

\markup \bold { Combined: }
\divisibleStaff "Violin" \music


example.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Context order

[Samuel Speer]

Hi list,

I'm wondering if there is a simple way to keep the PianoStaff at the bottom
of the vertical group, regardless of contexts being created / destroyed
above it.

Basically, I've created a ChoirStaff with non-simultaneous music and
grouped it with the PianoStaff:

<<

  ChoirStaff <<
 {
 << First line of music >>
 << Next line of music >>
 << Third line of music >>
  }
   >>

  PianoStaff <<
{ All lines of music combined }
  >>

>>

In the attached pdf, you'll see that the PianoStaff jumps to the top on the
second line when new contexts are created inside the ChoirStaff. Can I
force the PianoStaff to the bottom? I tried AlignBelowContext, but I think
that only works for lyrics.

I've attached a full (longer) example.

Samuel.
\score {
  <<
\new ChoirStaff <<
  {
% First line - parts unison
<<
  \new Staff { c' c' c' c'}
  \new Staff { a a a a }
>>

% Second line - high parts split
<<
  \new ChoirStaff \with { systemStartDelimiter = #'SystemStartSquare } <<
\new Staff { g' g' g' g' }
\new Staff { c' c' c' c' }
  >>
  \new Staff { a a a a }
>>

% Third line - low parts split
<<
  \new ChoirStaff \with { systemStartDelimiter = #'SystemStartSquare } <<
\new Staff { g' g' g' g' }
\new Staff { c' c' c' c' }
  >>
  \new ChoirStaff \with { systemStartDelimiter = #'SystemStartSquare } <<
\new Staff { a a a a }
\new Staff { f f f f }
  >>
>>
  }
>>

\new PianoStaff <<
  \new Dynamics { s1 \break s1 \break s1 \break }
  \new Staff { c'4 c' c' c' |  q q q | q q q q |}
  \new Staff { a a a a | a a a a |  q q q | }
>>
  >>

  \layout {
\context { \Staff
  \RemoveEmptyStaves
}
  }
}

scoretest.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Context order

[Janek Warchoł]

Hi,

2014-08-28 19:21 GMT+02:00 Samuel Speer :
> Hi list,
>
> I'm wondering if there is a simple way to keep the PianoStaff at the bottom
> of the vertical group, regardless of contexts being created / destroyed
> above it.
>
> Basically, I've created a ChoirStaff with non-simultaneous music and grouped
> it with the PianoStaff:
>
> <<
>
>   ChoirStaff <<
>  {
>  << First line of music >>
>  << Next line of music >>
>  << Third line of music >>
>   }
>>>
>
>   PianoStaff <<
> { All lines of music combined }
>   >>
>
>>>
>
> In the attached pdf, you'll see that the PianoStaff jumps to the top on the
> second line when new contexts are created inside the ChoirStaff. Can I force
> the PianoStaff to the bottom? I tried AlignBelowContext, but I think that
> only works for lyrics.

AFAIK AlignBelow/AboveContext should work (but you may have to use it
on the other context, i.e. voices instead of the piano).

However, i think that you actually should use another approach for
what you're doing (i.e. not spawn new contexts when the voices split).
You may find thread "How split SA staff into two staff - each now has
two voices?" helpful for that.  Interestingly, i have just a few
minutes ago started another discussion on this very topic, see
"partcombine/divisi framework - let the fun begin!" thread.

hth,
Janek

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

Re: partcombine/divisi framework - let the fun begin!

[Janek Warchoł]

2014-08-28 19:23 GMT+02:00 Janek Warchoł :
> I attach a first version and i'd be interested in your comments.

PS this code requires LilyPond 2.19.13, which has not yet been
released.  Anyone wishing to try out the example should compile
LilyPond from source; take a look at
https://github.com/janek-warchol/cli-tools/blob/master/lilypond/intro-text.md
https://github.com/janek-warchol/cli-tools/blob/master/lilypond/build-lily.sh
for a user-friendly way of doing this.

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

would 'gn' for G-natural be useful in \language "english" ?

[Keith OHara]

Dear user list,
  The suggestion quoted below from the bug-lilypond list

makes sense to me, as an addition to the \language "english"  note-names.

It would not fit in German-style pitch-names, where 'cis' and 'ces' get 
completely distinct names from 'c'.
I am not sure if something similar makes sense in fixed-do naming as used in 
French and Spanish.

Would anyone else like to see 'fn' as a second way to express F-natural in 
English (in addition to the existing 'f') ?


David Winfrey <> writes:


A new accidental for entering natural notes would be useful.
In English, this would be 'n', as in 'bn4' or 'gn2'.
These would have exactly the same effect as 'b4' or 'g2',
but would be easier to debug.
If the user is entering or editing music in the key of F,
or some other key where B is normally flat, it is often
not clear if 'b4' was intended to be B-natural, or if
someone just forgot to flat it.
If the note is written as 'bn4', the note was clearly
meant to be B-natural.



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

Re: partcombine/divisi framework - let the fun begin!

[Keith OHara]

Janek Warchoł  gmail.com> writes:

> I'm working on putting together a set of functions for handling parts
> that split into multiple voices and/or staves


> Attachment (definitions.ily): text/x-lilypond, 2359 bytes
> Attachment (example.ly): text/x-lilypond, 825 bytes
> Attachment (example.pdf): application/pdf, 33 KiB

I like the way 'definitions.ily' uses <<>> parallel music constructions
to ensure that the parts re-synchronize even if there is a note missing
in the input.  

You should do something similar for the \together segments.
As you have it now, the together segments are un-tagged, so are included
in all three staves (two of which are not printed).
But if someone uses these definitions with music that uses tags for 
some other purpose, the tagged music will be left out.







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