It's strange, I tested with a project that had some "rebel ties", commented
out the previous fix and used \tieDown, and the ties went in the direction
I wanted them to... I'll have to look at it in more detail, but it must
surely be my fault, I must have missed something.
However in the example abo
Hi Stéfano,
I tested with the force-rebel-tie.ly file you sent earlier in this
thread. What I meant was that \tieDown still does have no effect, when
there is a \voiceOne statement - maybe hidden via << \\ >>. So the first
tie is not changed with the EE-mod in the demo.
Do you think the warni
I wanted to let you know that I have tried the refactor-override branch and
the overrides seem to be working fine! I do get a lot of warnings as you
explained, but it does not appear the the EE overrides are getting
overwritten, or maybe I'm misunderstanding your explanation?
2018-03-13 13:50 GMT-
Hi Jan-Peter,
Thank you for your work! I will test the changes later today and let you
know how it results.
2018-03-13 7:47 GMT-03:00 Jan-Peter Voigt :
> Am 13.03.2018 um 11:37 schrieb David Kastrup:
>
>> Jan-Peter Voigt writes:
>>
>> Hi Stefano,
>>>
>>> I have been looking into the issue and c
Am 13.03.2018 um 11:37 schrieb David Kastrup:
Jan-Peter Voigt writes:
Hi Stefano,
I have been looking into the issue and created a branch
'refactor-override' for the edition-engraver.
The following is changed in there:
* Overrides are not applied "by hand" but send as a StreamEvent so
that on
Jan-Peter Voigt writes:
> Hi Stefano,
>
> I have been looking into the issue and created a branch
> 'refactor-override' for the edition-engraver.
> The following is changed in there:
> * Overrides are not applied "by hand" but send as a StreamEvent so
> that once is handled by lily and not the EE
Hi Stefano,
I have been looking into the issue and created a branch
'refactor-override' for the edition-engraver.
The following is changed in there:
* Overrides are not applied "by hand" but send as a StreamEvent so that
once is handled by lily and not the EE
* Override (and Revert, Set, Unset
Thank you, David! Sometimes I need a pointer to the obvious ...
* I will refactor the EE to also broadcast overrides.
* Of course I can listen to Overrides (and SetProperty) and check if
there are editionMods and music colliding - the reason they didn't show
up when I listened to StreamEvent was
Jan-Peter Voigt writes:
> Hi David,
>
> Am 05.03.2018 um 10:42 schrieb David Kastrup:
>>> This is a failure that can happen whenever there are (implicit)
>>> overrides in the music. I'll try to track/fetch overrides generated
>>> outside the EE to avoid this issue.
>> Any chance to actually use t
Hi David,
Am 05.03.2018 um 10:42 schrieb David Kastrup:
This is a failure that can happen whenever there are (implicit)
overrides in the music. I'll try to track/fetch overrides generated
outside the EE to avoid this issue.
Any chance to actually use the equivalent of "\once" here? It's
protec
Jan-Peter Voigt writes:
> Hi Stefano,
>
> thanks again for bringing up this issue! Now I identified it an EE-bug
> and I was able to reproduce the failure with:
> --
> \version "2.19.80"
> \include "oll-core/package.ily"
> \loadPackage edition-engraver
Hi Stefano,
thanks again for bringing up this issue! Now I identified it an EE-bug
and I was able to reproduce the failure with:
--
\version "2.19.80"
\include "oll-core/package.ily"
\loadPackage edition-engraver
\consistToContexts #edition-engraver V
Hi Stefano,
thanks a lot for researching this issue! Sometimes I also noticed "rebel
ties", but I didn't identified it as an EE bug. So your research file
looks meaningful.
I hope to have a deeper look into it next week.
Best
Jan-Peter
Am 26.02.2018 um 15:26 schrieb Stefano Troncaro:
Hi ever
Hi everyone! I tried to isolate the issue with Tie directions that I posted
earlier and I'm fairly confident I've stumbled upon a bug.
Look at the output of this snippet (Sorry for the length, I made it as
short as I could)
> \version "2.19.80"\language "english"\include
> "oll-core/package.ily"
14 matches
Mail list logo
