lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Context paths (and the Edition Engraver)


From: Carl Sorensen
Subject: Re: Context paths (and the Edition Engraver)
Date: Tue, 21 Jan 2020 19:02:29 +0000
User-agent: Microsoft-MacOutlook/10.10.10.191111


On 1/21/20, 11:19 AM, "lilypond-devel on behalf of Dan Eble" 
<lilypond-devel-bounces+c_sorensen=address@hidden on behalf of address@hidden> 
wrote:

    On Jan 21, 2020, at 11:31, Jan-Peter Voigt <address@hidden> wrote:
    > 
    > \context Voice = choir.soprano
    > 
    > it would be inconsistent with \new <Context> = "…"
    
    The implied example
    
       \new Voice = choir.soprano { … }
    
    could be given a consistent interpretation.  For example, it could be 
interpreted as creating \new Voice = soprano { … } within an existing-or-new 
context of unspecified type and ID "choir".
    
    If we decide what we want from \context first, it will probably be pretty 
obvious how \new should work.


\new ChoirStaff = choir  <<
    \new Staff = choir.upper  <<
        \new Voice = choir.upper.soprano
        \new Voice = choir.upper.alto
    >>
   \new Staff = choir.lower <<
        \new Voice = choir.lower.tenor
        \new Voice = choir.lower.bass
   >>
>>

Or would we prefer

\new ChoirStaff = choir  <<
    \new Staff = choir.upper  <<
        \new Voice = choir.soprano
        \new Voice = choir.alto
    >>
   \new Staff = choir.lower <<
        \new Voice = choir.tenor
        \new Voice = choir.bass
   >>
>>

The first example is potentially problematic, because Voices can change Staffs 
(and even StaffGroups), so it seems that having the Voice id include the Staff 
is not desirable.

Our current \change Staff command does a find such that it will find the staff 
in the current StaffGroup if it exists, and if not it will look in other 
StaffGroups.

\version "2.19.83"

\new StaffGroup <<
  \new ChoirStaff = "choir" <<
    \new Staff = "ch_upper" <<
      \new Voice = "soprano" {
        \voiceOne
        a' b' c'' d''
      }
      \new Voice = "alto" {
        \voiceTwo
        f' g' \change Staff ="ch_lower" a' b'
       % f' g' \change Staff ="LH" a' b'
      }
    >>
    \new Staff = "ch_lower" <<
      \new Voice = "tenor" {
        \voiceOne 
        s1
      }
      \new Voice = "bass" {
        \voiceTwo 
        s1
      }
    >>
  >>
  \new PianoStaff = "piano" <<
    \new Staff = "ch_lower" <<
       \new Voice = "soprano" {
      c4 d e f
       }
    >>
    \new Staff = "LH" <<
      \new Voice = "bass" {
        \voiceTwo
        a4 b \change Staff = "ch_lower" c d
      }
    >>
  >>
>>


It seems to me that 

\context StaffGroup ID1.ID2.ID3.ID4

(where StaffGroup ID1 exists)

Should find StaffGroup ID1, then find a child context ID2 of StaffGroup ID1,
Then find a child context ID3 of ID2,
Then find a child context ID4 of ID3.

In this particular example, ID2 must be some form of a StaffGroup, IIUC, 
because ID4 must be a bottom context, and ID3 must be a context that takes a 
bottom context (e.g. Staff or TabStaff), and ID2 must be a context that takes a 
Staff (e.g StaffGroup, ChoirStaff, PianoStaff).

I think that we must consider all of the possibilities currently in lilypond 
before changing to this form of notation.  I personally find the lilypond 
concept that voices exist independently of staves although they are always 
expressed in a staff at any point in time to be far more powerful than the 
MusicXML concept that voices exist in staves.

Thanks,

Carl
 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]