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 16:40:59 +0000
User-agent: Microsoft-MacOutlook/10.10.10.191111


´╗┐On 1/19/20, 2:42 PM, "lilypond-devel on behalf of Dan Eble" 
<lilypond-devel-bounces+c_sorensen=address@hidden on behalf of address@hidden> 
wrote:

    One of the things in Kieren's intro to the Edition Engraver (EE) that 
resonated with me was the context paths.  His example was something like 
`singwithbach.along.Voice.B`, which was supposed to refer to something like 
this:
    
      \context Staff = "along" {
        \context Voice = "B" {
          ...
        }
      }
    
    The ability to refer to contexts this way is a great idea, though IMHO it 
needs some work to reduce ambiguity.  But the point I came here to make is 
this: if an EE using a similar syntax is ever to be a part of LilyPond proper, 
the syntax ought to be consistently supported for other LilyPond commands that 
refer to contexts.  For example,
    
      \context along.Voice.B { ... }
    
      \set along.Voice.B.property = #...
    
      \change Voice = ChoirStaff.A.Staff.B
    
    It would be wise to ask whether there are use cases for any "pronouns" 
(like `.` and `..` in file paths, and `this` in C++) to make it possible to 
root a search very specifically.  The existence of the `descend-only` music 
property suggests that there might be.  I also think I have a pretty good use 
case for finding "the closest enclosing context where a given property is 
defined," but I am not now prepared to elaborate.



All of this discussion about including the edition engraver and packages in 
LilyPond core is exciting to me.

I think that if we choose to do so, it should represent a major release for 
LilyPond, i.e. it should become LilyPond 3.0.  And it's possible that we will 
have some NOT_SMART convert.ly rules connected to the major release; users 
would potentially need to hand-code changes.

Thanks,

Carl
 


reply via email to

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