Re: Prevents script tie collisions (issue 6500058)

[address@hidden]

On 4 sept. 2012, at 07:36, address@hidden wrote:

> I can't get it to work for the script at the start of the tie.
> \relative c''' { r2. c4~-> | c-> r2. }
> 

The reason is because ties are announced at a timestep (maybe several) after 
their creation.  This makes it very difficult to account for scripts created on 
the first tied note.

What would be best is for the tie engraver to announce ties straightaway and 
then to call Grob::suicide if they wind up not being used instead of announcing 
them later.  It leads to a proliferation of more grobs but as they're suicided 
before the preprocessing of graphical objects they don't eat up computation 
time.  This is how flags are created in the Stem_engraver - they don't know if 
they'll have a beam until the Auto_beam_engraver finishes off a beam, so we 
create more than necessary and kill off the unused ones later.

> 
> http://codereview.appspot.com/6500058/diff/1/input/regression/script-tie.ly
> File input/regression/script-tie.ly (right):
> 
> http://codereview.appspot.com/6500058/diff/1/input/regression/script-tie.ly#newcode10
> input/regression/script-tie.ly:10: r2. c4 ~ |
> r2. c4-> ~
> 
> http://codereview.appspot.com/6500058/diff/1/lily/script-engraver.cc
> File lily/script-engraver.cc (right):
> 
> http://codereview.appspot.com/6500058/diff/1/lily/script-engraver.cc#newcode54
> lily/script-engraver.cc:54: set<Grob *> ties_;
> Ties only affect the note at their beginning and at their end, so I do
> not see the need to remember them.   Can't you just add them to the
> support of a script immediately upon acknowledging their beginnings and
> ends?
> 

Good call.

> http://codereview.appspot.com/6500058/diff/1/lily/script-engraver.cc#newcode226
> lily/script-engraver.cc:226: ties_.erase (ties_to_remove_[i]);
> It looks, to me, like you erase any tie ending on this note /before/ you
> tell any scripts on this not about the tie.
> However, it works at this end of the tie so I must be misunderstanding
> something.

See above - it's a problem of the moment of announcement versus the actual 
timestep where the grob's creation happens.

> 
> http://codereview.appspot.com/6500058/
> 
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel