Re: Interesting glitch when using tags ...

[Wols Lists]

On 04/02/18 19:20, David Kastrup wrote:
> Wol's lists <address@hidden> writes:
> 
>> Okay. You wanted a minimal example ...
>>
>> But surely, "f4. ~ f4" is clearly something wrong if it's complaining
>> about an unterminated tie? Yes you might need a bit more information
>> to debug it, but on the face of it it's a blatant bug ...
> 
> And when looking closer at an actual example, it isn't.
> 
> \version "2.18.2"
> 
> \include "english.ly"
> 
> 
> \score {
>     \new Staff {
>         \time 6/8
>         \key bf \major
>         \clef "treble_8"
>         << 
>             {
>                 \repeat percent 4 { bf8[ r bf] bf[ r bf] } | c4( d8 c4) r8 | 
> c8-> r4 c8-> r4 | c2. | c2. ~ 
>             }
>             {
>                 \repeat percent 4 { f8[ r f] f[ r f] } | f4. ~ f4 r8 | a8-> 
> r4 a8-> r4 | a2. | bf2.
>             }
>         >>
>     }
> }
> 
> The problem here is that your two melody passages are all in the same
> voice, and that means that f4 is _not_ the next note after f4. ~ but
> rather the d8 in the previous line of entry is.

Oh ... so lily is being its usual rather non-intuitive self :-) (Of
course, being a command line tool, with power comes responsibility :-)
> 
> LilyPond cannot deal sensibly with overlapping notes in the same voice.
> You need two separate voices.  Indeed, putting \\ between the two { }
> groups in the parallel music stops the problem.  Of course, with awful
> voice crossing. 

I'll see what doing that does. Bear in mind, in the full example they
are tagged ...

 Putting \voices 2,1 before the << ... >> looks better
> (but I have no idea whether the voice crossing then in the first half is
> intentional, or even whether you wanted the original in which case you'd
> like be better off with two staves).

The original is a part with two instruments, so no, two staves is very
definitely not what is wanted - and the tags are so that I can print it
out for my own purposes as two separate parts, but print it combined for
checking purposes. Can be painful :-(

Maybe I should have done it as two separate parts, and used partcombine
for checking purposes. Would probably have been easier ...
> 
> So can we agree that diagnosing this required an actual complete example
> showing the context in which this problem occured?
> 
(Which, while it wasn't a compilable example, was why I included the
context in my first post :-)

Anyways, thanks. Now I know why it's happening, I can either choose to
ignore it, or I can fix it. And next time it happens, I'll know what's
going on.

Cheers,
Wol