Re: Removes cross-staff beams from the collision grob array (issue4432063)

[Han-Wen Nienhuys]

On Sat, Apr 23, 2011 at 10:18 PM,  <address@hidden> wrote:
> On 2011/04/24 01:03:23, hanwenn wrote:
>
> http://codereview.appspot.com/4432063/diff/3001/lily/beam-collision-engraver.cc
>>
>> File lily/beam-collision-engraver.cc (right):
>
>
> http://codereview.appspot.com/4432063/diff/3001/lily/beam-collision-engraver.cc#newcode110
>>
>> lily/beam-collision-engraver.cc:110: && !covered_grobs_[j].event_cause
>
> ())))
>>
>> rather than doing this kind of decision in the engraver, can you do it
>
> in the
>>
>> typesetting backend itself?  You could make cross-staff beams ignore
>
> just
>>
>> stems/beams and continue doing collisions for clefs, accidentals, etc.
>
> Would this need to be done in both beam-quanting.cc and beam.cc?

beam.cc already has a filtering pass in shift_positition_to_valid().
If you add the filtering there it will work for beam-quanting.cc too

In general, I think it is better for the backend to deal with this, as
the backend should be robust against 'invalid' configuration by the
engraver system anyway.

> In general, I am reticent to make grob-by-grob exceptions to a procedure
> that should seemingly be grob-agnostic.

it's already not grob-agnostic: it is aware of the difference between
beams and stems.

are you sure you're not just less hesitant about changing the engraver
than the backend because you wrote it yourself, and are therefore more
familiar with it?

> I have a semi-idea for how to fix this, but it'll take me a couple days
> to make it into a full idea.  The gist is to move the
> beam-collision-engraver up to the score level and then populate the
> covered-grob list based on the beam's staves by using grobs that share a
> staff symbol with a given stem around that stem's rank.  This way,
> cross-staff beams can take grobs from all staves to which they belong
> into consideration.

For getting x-staff beaming completely right, I agree that the
engraver needs to move up.

I'm a bit hesitant about bolting this onto the current design.

What are the performance characteristics for the beam-coll engraver at
staff level for large scores (eg. 50 staves)?  The looping (all beams
x all grobs that start around a beams start point) seems suboptimal to
me.

Another option:

  map<context*, vector<grob*>>  context_grobs_  // sorted

and a

 map<grob*, context*> covered_ // staff origin for each grob

ie. a sorted list per context, and then

  int min, max;
  for (b : beams) { // beams is sorted
    set<context*> contexts = ...  // get beam's contexts

    for (cont : context_grobs_) {
      // update min/max indices so they cover b
    }

    for (c : contexts) {
      grobs = context_grobs_[c]
      start, end  = .. . // binary search to start point/end point of
beam; use a global minimum/maximum to initate search
      for (cov : grobs[start : .. ])  {
        // consider adding cov to b.
      }
    }
  }

on second thought, this may be too tricky for a first cut.


>
> http://codereview.appspot.com/4432063/
>



-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen