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
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
