[Top][All Lists]

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

Re: Context paths (and the Edition Engraver)

From: Jan-Peter Voigt
Subject: Re: Context paths (and the Edition Engraver)
Date: Tue, 21 Jan 2020 17:31:27 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

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 = #...
>>>  \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 "" (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 :)


reply via email to

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