Context paths (and the Edition Engraver)

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Context paths (and the Edition Engraver)

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

Dan


dak
Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

dak
Dan Eble <[hidden email]> writes:

> 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 think that this would warrant closely analysing what the EE does and
checking whether its way of specifying things is a natural match to what
might be useful with LilyPond, or at least can be made so without
impacting its usefulness.  It seems that the applicability inside of
LilyPond currently is sufficiently vague that merging EE and LilyPond
core usage in that manner makes sense only if the solution is not
awkward for either LilyPond or EE in some manner: we don't want subtly
different and/or less than useful semantics.

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

Comments from the EE crowd?

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Kieren MacMillan
Hi all,

[Single-level quotes are David Kastrup’s; double-level quotes are Dan Eble’s.]

> Comments from the EE crowd?

Not sure how much of a "crowd" we are…  ;)

>> One of the things in Kieren's intro to the Edition Engraver (EE) that resonated with me was the context paths.
[…]
>> The ability to refer to contexts this way is a great idea, though IMHO it needs some work to reduce ambiguity.

I agree on both points. (Perhaps one of my first contributions in 2020 should be a less-ambiguous set of documented examples for the EE?)

>>  \context along.Voice.B { ... }
>>  \set along.Voice.B.property = #...
>>  \change Voice = ChoirStaff.A.Staff.B

An interesting proposal.

> I think that this would warrant closely analysing what the EE does and
> checking whether its way of specifying things is a natural match to what
> might be useful with LilyPond, or at least can be made so without
> impacting its usefulness.

Agreed.

Perhaps instead of the current

   \new Staff = "piano_upper"

mechanism, we could have a

   \new Staff piano.upper

"id" that could be used for addressing by both Lilypond proper *and* the EE [or any other extension/addon]? Other than the obvious coding requirement to make the switch, is there any real impact on Lilypond itself switching from '= "name"' syntax to 'name' syntax? Even if Lilypond didn’t yet recognize/react to a path like "score.ps.piano.upper.Voice.A" (the way the EE already does), such a change would at least align the two labelling/addressing methods.

Alternatively, we could consider changing the EE to do addressing the way it’s done in Lilypond proper… but I feel like that would be a step backwards.

>> It would be wise to ask whether there are use cases
>> for any "pronouns" (like `.` and `..` in file paths, and `this`

Interesting… Because of the way timing works (or, in this case, doesn’t!) in the EE, I sometimes have to write (e.g.)

   \editionMod my-edition 10 1/4 id-to-a-staff.Score \override …

because addressing the Score directly doesn’t work at that moment. I suppose this would be a possible place for "addressing pronouns" and the like.

> we don't want subtly different and/or less than useful semantics.

Agreed.

>> I also think I have a pretty good use case for finding "the closest
>> enclosing context where a given property is defined,"

I believe I could imagine a lot of such use cases.  =)

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Jan-Peter Voigt
Hi there,

> [Single-level quotes are David Kastrup’s; double-level quotes are Dan Eble’s.]
>
>> Comments from the EE crowd?
>
> Not sure how much of a "crowd" we are…  ;)
at least we are 2 :)


>>> One of the things in Kieren's intro to the Edition Engraver (EE) that resonated with me was the context paths.
> […]
>>> The ability to refer to contexts this way is a great idea, though IMHO it needs some work to reduce ambiguity.
>
> I agree on both points. (Perhaps one of my first contributions in 2020 should be a less-ambiguous set of documented examples for the EE?)
that would of course be helpful, because my examples will always along
my development ideas and not along a foreign users view ...

>>>  \context along.Voice.B { ... }
>>>  \set along.Voice.B.property = #...
>>>  \change Voice = ChoirStaff.A.Staff.B
>
> An interesting proposal.
I'd like that, though it would be a quite invasive change.
And if we stay with the string for the context id and then use
lists/paths in the \context statement like
\new Staff = "choir" << \new Voice = "soprano" …

and then use
\context Voice = choir.soprano

it would be inconsistent with \new <Context> = "…"

I will write down some more text about this topic later.

>> I think that this would warrant closely analysing what the EE does and
>> checking whether its way of specifying things is a natural match to what
>> might be useful with LilyPond, or at least can be made so without
>> impacting its usefulness.
>
> Agreed.
>
> Perhaps instead of the current
>
>    \new Staff = "piano_upper"
>
> mechanism, we could have a
>
>    \new Staff piano.upper
Though I'd like such a scheme, I'd not recommend it, because I see
breaking changes coming up ;)


> "id" that could be used for addressing by both Lilypond proper *and* the EE [or any other extension/addon]? Other than the obvious coding requirement to make the switch, is there any real impact on Lilypond itself switching from '= "name"' syntax to 'name' syntax? Even if Lilypond didn’t yet recognize/react to a path like "score.ps.piano.upper.Voice.A" (the way the EE already does), such a change would at least align the two labelling/addressing methods.
>
> Alternatively, we could consider changing the EE to do addressing the way it’s done in Lilypond proper… but I feel like that would be a step backwards.
>
>>> It would be wise to ask whether there are use cases
>>> for any "pronouns" (like `.` and `..` in file paths, and `this`
The dots are from the dot-notation of lists. If you type

lst = "..".hui.buh
#(display lst)

you can see that `lst` is a list with symbols #'(.. hui buh)

In my templates package I have function to canonicalize such paths. I
will import that to the EE.

> Interesting… Because of the way timing works (or, in this case, doesn’t!) in the EE, I sometimes have to write (e.g.)
>
>    \editionMod my-edition 10 1/4 id-to-a-staff.Score \override …
this works? I thought you'D need
   \editionMod my-edition 10 1/4 id-to-a-staff \override Score.…


I hope to work on the discussed topics soon, but my desktop is stuffed ...

It was an amzing weekend! Thank you all :)

Jan-Peter

Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Carl Sorensen-3
In reply to this post by Dan Eble


On 1/19/20, 2:42 PM, "lilypond-devel on behalf of Dan Eble" <lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of [hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Kieren MacMillan
In reply to this post by Jan-Peter Voigt
Hi Jan-Peter,

>> Not sure how much of a "crowd" we are…  ;)
> at least we are 2 :)

Well, how many more until we gain official "crowd" status?  =)

>> I agree on both points. (Perhaps one of my first contributions in 2020 should be a less-ambiguous set of documented examples for the EE?)
> that would of course be helpful, because my examples will always along
> my development ideas and not along a foreign users view ...

I’ll put it on my list. I’m wanting things to do with all this inspired energy, but real development should (I believe) wait until after any big "process" changes are complete… so I’m left with (1) learning Scheme, and (2) documentation and examples.

>>   \editionMod my-edition 10 1/4 id-to-a-staff.Score \override …
> this works? I thought you'D need
>   \editionMod my-edition 10 1/4 id-to-a-staff \override Score.…

You are correct — apologies for my jet-lag-brain noise.

Best,
Kieren.
________________________________

Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Kieren MacMillan
In reply to this post by Carl Sorensen-3
Hi Carl,

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

+1

> 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

If we really get a great extension/package management system rolled in (even if the EE itself remains "outside" the core), I would definitely vote for incrementing the major version number.

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

We should, of course, try to avoid that entirely where possible, and mitigate it otherwise.

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Dan Eble
In reply to this post by Jan-Peter Voigt
On Jan 21, 2020, at 11:31, Jan-Peter Voigt <[hidden email]> wrote:

> I'd like that, though it would be a quite invasive change.
> And if we stay with the string for the context id and then use
> lists/paths in the \context statement like
> \new Staff = "choir" << \new Voice = "soprano" …
>
> and then use
> \context Voice = choir.soprano
>
> it would be inconsistent with \new <Context> = "…"
>
> I will write down some more text about this topic later.

I see similarities with languages like CSS and XPATH select nodes in a DOM.  Notation borrowed directly from them will not integrate well into LilyPond, but it might be fruitful to ask how we could modify expressions like these to fit in.

    %% find the voice in the example quoted above, very specifically
    \context Staff#choir > Voice#soprano { … }         % CSS
    \context Staff[@id=choir]/Voice[@id=soprano] { … } % XPATH

    %% ditto, but using context type only
    \context Staff > Voice { … }                       % CSS
    \context Staff/Voice { … }                         % XPATH

    %% ditto, but using ID only
    \context #choir > #soprano { … }                   % CSS
    \context [@id=choir]/[@id=soprano] { … }           % XPATH

    %% find the context where the rehearsalMark property is defined
    \context [rehearsalMark] { … }                     % CSS
    \context [@rehearsalMark] { … }                    % XPATH

Dan


Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Dan Eble
In reply to this post by Jan-Peter Voigt
On Jan 21, 2020, at 11:31, Jan-Peter Voigt <[hidden email]> 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.

Dan


Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Carl Sorensen-3


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

    On Jan 21, 2020, at 11:31, Jan-Peter Voigt <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Dan Eble
On Jan 21, 2020, at 14:02, Carl Sorensen <[hidden email]> wrote:

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

I don't think anyone was suggesting that a context ID would include the IDs of its parents as a substring.  At least I wasn't trying to suggest that.  The idea is that something like this:

    \context foo.bar.baz { … }

Could be interpreted as shorthand for this:

    \context %{ unspecified %} = foo {
      \context %{ unspecified %} = bar {
        \context %{ unspecified %} = baz { … }
      }
    }


Dan


Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Kieren MacMillan-4
In reply to this post by Carl Sorensen-3
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 | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Kieren MacMillan
In reply to this post by Dan Eble
Hi all,

> I don't think anyone was suggesting that a context ID would include the IDs of its parents as a substring. At least I wasn't trying to suggest that.  The idea is that something like this:
>
>    \context foo.bar.baz { … }
>
> Could be interpreted as shorthand for this:
>
>    \context %{ unspecified %} = foo {
>      \context %{ unspecified %} = bar {
>        \context %{ unspecified %} = baz { … }
>      }
>    }

Exactly.
Kieren.
________________________________

Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


dak
Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

dak
In reply to this post by Dan Eble
Dan Eble <[hidden email]> writes:

> On Jan 21, 2020, at 11:31, Jan-Peter Voigt <[hidden email]> wrote:
>> I'd like that, though it would be a quite invasive change.
>> And if we stay with the string for the context id and then use
>> lists/paths in the \context statement like
>> \new Staff = "choir" << \new Voice = "soprano" …
>>
>> and then use
>> \context Voice = choir.soprano
>>
>> it would be inconsistent with \new <Context> = "…"
>>
>> I will write down some more text about this topic later.
>
> I see similarities with languages like CSS and XPATH select nodes in a
> DOM.  Notation borrowed directly from them will not integrate well
> into LilyPond, but it might be fruitful to ask how we could modify
> expressions like these to fit in.
>
>     %% find the voice in the example quoted above, very specifically
>     \context Staff#choir > Voice#soprano { … }         % CSS
>     \context Staff[@id=choir]/Voice[@id=soprano] { … } % XPATH
>
>     %% ditto, but using context type only
>     \context Staff > Voice { … }                       % CSS
>     \context Staff/Voice { … }                         % XPATH
>
>     %% ditto, but using ID only
>     \context #choir > #soprano { … }                   % CSS
>     \context [@id=choir]/[@id=soprano] { … }           % XPATH
>
>     %% find the context where the rehearsalMark property is defined
>     \context [rehearsalMark] { … }                     % CSS
>     \context [@rehearsalMark] { … }                    % XPATH
> —
> Dan

The syntax appears not to be a good match to LilyPond even though the
concept may be considered fitting.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Dan Eble
On Jan 21, 2020, at 14:20, David Kastrup <[hidden email]> wrote:
>
>> Notation borrowed directly from them will not integrate well
>> into LilyPond, but it might be fruitful to ask how we could modify
>> expressions like these to fit in.
...
> The syntax appears not to be a good match to LilyPond even though the
> concept may be considered fitting.

I'm glad you agree.

Dan


Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Dan Eble
In reply to this post by Carl Sorensen-3
On Jan 21, 2020, at 14:02, Carl Sorensen <[hidden email]> wrote:
> It seems to me that
>
> \context StaffGroup ID1.ID2.ID3.ID4
...
> ID4 must be a bottom context

Please guide me step by step to this conclusion.  All this example speaks to me is that ID4 is a great-grandchild of ID1.

Thanks and regards,

Dan


dak
Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

dak
In reply to this post by Dan Eble
Dan Eble <[hidden email]> writes:

> On Jan 21, 2020, at 14:20, David Kastrup <[hidden email]> wrote:
>>
>>> Notation borrowed directly from them will not integrate well
>>> into LilyPond, but it might be fruitful to ask how we could modify
>>> expressions like these to fit in.
> ...
>> The syntax appears not to be a good match to LilyPond even though the
>> concept may be considered fitting.
>
> I'm glad you agree.

StaffGroup = "organ" . Staff = "upper" . Voice . SubVoice = 2
#'((StaffGroup . organ) (Staff . upper) Voice (SubVoice . 2))

Does this give us a hook into making \set, \override and/or \tempo a
music function in the long run?  Less than sure about that.
Particularly \tempo appears rather tricky.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Carl Sorensen-3
In reply to this post by Dan Eble


On 1/21/20, 12:32 PM, "Dan Eble" <[hidden email]> wrote:

    On Jan 21, 2020, at 14:02, Carl Sorensen <[hidden email]> wrote:
    > It seems to me that
    >
    > \context StaffGroup ID1.ID2.ID3.ID4
    ...
    > ID4 must be a bottom context
   
    Please guide me step by step to this conclusion.  All this example speaks to me is that ID4 is a great-grandchild of ID1.

You are correct, of course.

Thanks,

Carl
 

Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

Dan Eble
In reply to this post by dak
On Jan 21, 2020, at 14:37, David Kastrup <[hidden email]> wrote:
>
> StaffGroup = "organ" . Staff = "upper" . Voice . SubVoice = 2

OK.  It would be an understandable growth on the current face of LilyPond. :)

Questions follow, but I'm not asking you to spend time investigating.

Do you think we could achieve making the quotes optional for some simple IDs, and making the whitespace optional?

    StaffGroup=organ.Staff=upper.Voice.SubVoice=2

In a situation where the user didn't care to constrain the context types, do you think could they be omitted, or would we have to invent a placeholder?

    =organ.=upper..=2
    X=organ.X=upper.X.X=2

Maybe--MAYBE--I'm not yet advocating it, but maybe we could allow some ambiguity when there is no equal sign, and define how LilyPond resolves it; like if it is a context type then it is used as the context type, otherwise it is used as an ID, which would allow things like this:

    organ.upper.Voice.2

> Does this give us a hook into making \set, \override and/or \tempo a
> music function in the long run?  Less than sure about that.
> Particularly \tempo appears rather tricky.

If I ever knew enough about the implementation of those to answer, I've forgotten it.

Dan
dak
Reply | Threaded
Open this post in threaded view
|

Re: Context paths (and the Edition Engraver)

dak
Dan Eble <[hidden email]> writes:

> On Jan 21, 2020, at 14:37, David Kastrup <[hidden email]> wrote:
>>
>> StaffGroup = "organ" . Staff = "upper" . Voice . SubVoice = 2
>
> OK.  It would be an understandable growth on the current face of LilyPond. :)
>
> Questions follow, but I'm not asking you to spend time investigating.
>
> Do you think we could achieve making the quotes optional for some
> simple IDs, and making the whitespace optional?
>
>     StaffGroup=organ.Staff=upper.Voice.SubVoice=2

It would all be optional (except in \lyricsmode or \markup) but I am
skeptical that it would make for a great convention.

> In a situation where the user didn't care to constrain the context
> types, do you think could they be omitted, or would we have to invent
> a placeholder?
>
>     =organ.=upper..=2
>     X=organ.X=upper.X.X=2

I don't think that this would be a reasonable syntax.

> Maybe--MAYBE--I'm not yet advocating it, but maybe we could allow some
> ambiguity when there is no equal sign, and define how LilyPond
> resolves it; like if it is a context type then it is used as the
> context type, otherwise it is used as an ID, which would allow things
> like this:
>
>     organ.upper.Voice.2

Picking this apart correctly would require knowing from the layout
definition which identifiers correspond to contexts.  That's nothing you
can do at music function execution time.  So you could check this path
for reasonability only at a rather late point of time.

Really looks too wishywashy to me to constitute a good idea.

>> Does this give us a hook into making \set, \override and/or \tempo a
>> music function in the long run?  Less than sure about that.
>> Particularly \tempo appears rather tricky.
>
> If I ever knew enough about the implementation of those to answer,
> I've forgotten it.

Hardwired in the parser.

--
David Kastrup

12