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: Kieren MacMillan
Subject: Re: Context paths (and the Edition Engraver)
Date: Tue, 21 Jan 2020 14:18:13 -0500

Hi all,

> \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
>   >>
> >>

To be honest, I’d prefer

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

though I understand that such a situation could introduce potential 
complexities (impossibilities?) once a score has more contexts [esp. of the 
same type] than what’s in that simple example.

> 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.

Hmmm… I would have thought the opposite: that it would [try to] find the 
StaffGroup which has ID4 as its identifier and which is the child of the 
context [of unknown type?] which has ID1.ID2.ID3 as its identifier/path. Am I 
the only one who thinks that way?

For my information: Does the alternative form

    \context "StaffGroup ID1".ID2.ID3.ID4

accurately/fairly represent how your suggestion is constructed?

> 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.

I totally agree.

Cheers,
Kieren.



reply via email to

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