Re: Questions about the edition engraver

[Noeck]

Hi Simon, Kieren, Urs and Jan-Peter,

thanks for all your replies!

>> 1. Can I use the same tweak at several points in time?

\editionModList is what I was looking for, thanks

>> 2. What do the letters mean in edition.Staff.A?
> 
> The [alphabetical] order of such contexts, from the top. So in your example, 
> Staff.B would correspond to your “mg”.
> 
> n.b. I have requested of Jan-Peter that the edition-engraver allow id- or 
> name-based addressing, so you could use "full-score.Staff.mg" or even just 
> “full-score.mg”; I don’t know the current status of that request.

That would be nice.

>> 2. What do the letters mean in edition.Staff.A?
>>     A numbering? How can I know which voice is which?
>>     Can I test that (like \displayEngraverNameHere)?
> When I started to implement it, I realized, that one has to identify 
> contexts, that share the same edition-engraver-id. So I added a counter. But 
> if I want to enter the ID with dot-notation, I may not use digits, but only 
> characters. So I count from A to Z, using capital letters to prevent taking 
> it as a pitch.
> I know that it is difficult to address Voices, when they are tagged from A to 
> Z ... but more on that later!

Thanks, that makes things clear.

>> 3. How can I address a temporary voice in some measure?
>>     a) One with << · \\ · >>?
>>     b) One with << · \new Voice { · } >>?
>>     (So far I
> There is an instantiation for an edition-engraver in every voice via a layout 
> declaration. If an edition-engraver is instantiated with #f for the id, it 
> looks into the parent context for an id. So if there is a Staff with an 
> \editionEngraver my.special.id , any voice created in this context will 
> consist an edition-engraver and can be addressed with 
> 'my.special.id.Voice.[A-Z]'. As mentioned above, it can be tedious to 
> identify the right voice. And OTOH it is not ideal, if you have to type 
> Score.A anytime, as there is only one Score for each score.
> Urs mentioned the pending pull-request, where I developed a change. I am 
> working in another project right now ... that is the reason I didn't have a 
> deeper look into the problem Urs mentioned ... time will come

In the log there are Voices up to P so I probably have much more voices
than I thought (I know of 4 or 6).
I suppose this means I should use a dedicated edition engraver for this
Voice to make it more robust even if I find the number of the Voice.

>> 4. What does the word 'edition' after the \editionEngraver mean?
>>     Can I choose this name? Why would I need more than one?
> As mentioned above, every instance of an edition-engraver has an id, so you 
> can address it. In the pull-request around the corner, the edition-engraver 
> takes
> 1. the id given as an argument
> or, if it is not a list,
> 2. the context-property 'edition-id
> or, if that is not a non-empty list,
> 3. the id of the parent contexts edition-engraver

To be a list, must there be always a dot in this name? Like 'mytest.id'?
Or is 'edition' equally fine?

>> 4. What does the word 'edition' after the \editionEngraver mean?
>>   Can I choose this name?
>
> Yes. And you should, as in my example above.
>
>> Why would I need more than one?
>
> Well, for example, ...
That makes sense. That way I might even be able to address a temporary
voice by adding a different engraver here in the \with block (I’ll have
to check).

>> 5. Can I put tweaks with the edition engraver?
>>     Like coloring the second of three note heads in a chord?
>>     { <c \tweak #'color #red e g> }
> Kieren said yes, but I think, I still have to implement it that way. I have 
> the idea to act on music found by a listener to add tweaks or to change 
> properties like the pitch. (the auto-transposer does it on that level)

I think Kieren meant \tweaks in general (not inside a chord). With the
listeners etc. you lost me, but that’s ok. I don’t need it right now.

>> 6. Would you consider \voiceOne etc. content or layout? \noBeam?
> I’d phrase it this way: everything that is decided by the
> composer/arranger is content, everything that is decided by the \
> typesetter/editor is presentation. Where exactly the border is to be >
drawn, depends.
I agree. (\noBeam already depends on the editions I know in some
cases, though.)

>> 7. Would you write a Dynamics context using spacer rests ...
answered.


> In the mentioned pull-request the addressing of contexts is streamlined.
> And I take the questions to continue development:
> 
> * create dynamics
Ok, but I agree with Kieren that this is more content than edition-layout.
> * add tweaks to single notes in an event chord
That would be nice. I don’t need it right now, though.

Thanks for all your answers! I think I can handle it now.

Cheers,
Joram