Thanks guys!
Urs, your explanation is very detailed and dissipated any remaining doubts
I had left about this issue.
Jan-Peter, I pulled the changes and after a quick test going through some
files everything seems to be working fine. I'll let you know if something
comes up.
About writing an explanation that I would have found useful, do want me to
email it to you? Send it to the list? Tell me how you wish to receive it
and I'll write it up.
I've stumbled over a few other things that don't behave as I expected, but
I don't yet know if it is related to the edition-engraver, to bad
structuring on my part, or to lack of knowledge of Lilypond's inner
workings. Whatever the case is, I'll make a new thread when I manage to
reproduce them in small contained examples.
Thank you again for all your help!
Stéfano
2018-01-27 12:15 GMT-03:00 Jan-Peter Voigt <jp.vo...@gmx.de>:
> Thank you for your feedback Stefano!
>
> I merged some code, which was pending quite some time. There was an issue
> with the first moment inside a context that is fixed now, *but* in your
> example it does not work (yet). This was quite tricky to track down: If you
> create a new Voice inside a new Voice on the first moment, but after some
> zero-length event (like clef) Voice creation and engraver initialization
> seems to be disturbed - in all voices.
> I'll try to track that down, when time allows!
> Your same example works, if you write
>
> \new Voice = "implied" << \clef F << ... >> >>
>
> that is, you replace the surrounding braces { } with << >> so that the
> clef-event appears simultaneously with the new Voices.
> I attach the modified version.
>
> HTH
> Jan-Peter
>
> P.S.: If something is messed up with after the merge, please let me know
> immediately!
>
>
> Am 26.01.2018 um 22:41 schrieb Stefano Troncaro:
>
>> Thank you Noeck.
>>
>> Your explanation makes sense and I feel it might be close to explaining
>> the issue, although in the log it appears as though the edition-engraver
>> only sees two voices, not three, thus refering to them as Voice.B and
>> Voice.C instead of A and B doesn't work either.
>>
>> Most intriguing to me is that if I explicitly create the voices as you
>> showed, so that no voices are created implicitly, like here:
>>
>> \new Staff \with { \editionID LH} { \new Voice ="Implied" {
>> \clef F << \new Voice ="LH_A" \relative c'{ \clef F \voiceOne e8
>> d c4 d8 c b4 | c8 b a2 g4 } \new Voice ="LH_B" \relative c{
>> \voiceTwo f2 e | d g,4 c |} >> } }
>>
>> Then I can't tweak the first note of either "LH_A" or "LH_B", but I /can/
>> tweak any of the following notes.
>>
>> Anyways, at least now I can use a structure that works properly, which
>> was the intent behind my original question. Although I'm still curious as
>> to what is the reasoning behind this behavior, it is clear that it far
>> exceeds my (lack of) understanding of the inner workings of Lilypond. So
>> it's unlikely I'll be able to find an explanation on my own. If someone
>> finds it I'll be more than grateful to hear it!
>>
>> I attached the full example of what I described above in case it is
>> useful to someone.
>>
>> To the openlilylib guys, since I'll be learning to use your tools, tell
>> me if I can be of use somehow.
>>
>> Thanks!
>> Stéfano
>>
>> 2018-01-26 16:07 GMT-03:00 Noeck <noeck.marb...@gmx.de <mailto:
>> noeck.marb...@gmx.de>>:
>>
>> Hi Stefano,
>>
>> if you write
>> { \clef F <<
>> as in your file eetest-not-working.ly <http://eetest-not-working.ly>
>> you have this in your Staff
>> context: \clef F and then afterwards two voices at the same time.
>> More explicitly, your code is interpreted as somthing like:
>>
>> \new Staff {
>> \new Voice { \clef F
>> <<
>> \new Voice ...
>> \new Voice ...
>> >>
>> }
>> }
>>
>> The \clef F can not be without bottom context so a Voice context is
>> created automatically. This is your voice A but it does not contain
>> notes.
>> Your explicit voices are probably named B and C (I have not checked)
>> so
>> you can address them via B and C.
>>
>> Or you can put the clef inside the first explicit voice which is then
>> A
>> again.
>>
>> HTH,
>> Joram
>>
>>
>> _______________________________________________
>> lilypond-user mailing list
>> lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>> <https://lists.gnu.org/mailman/listinfo/lilypond-user>
>>
>>
>>
>>
>> _______________________________________________
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>>
>
> _______________________________________________
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
