Hi Harm,
Ok, another 5 days passed working allday on the problem, progress: zero.
I give up.
Some insights:
(1)
It would have been helpful to understand how Stems fit into a Beam,
then I could use this knowledge to probably do similar with glissando
and Stems.
I was not able to figure it out.
(2)
Obviously the Stems needs to be positioned after Beam (or Glissando) is done.
An unpure-pure-container looked promising.
Though, I was not able to code even the simplest via native scheme.
This leads to the conclusion that unpure-pure-containers are not
accessible/customizable for users like me.
At least unless much more working examples are done in the docs.
I haven't had time to try and understand your issue, but having worked
on problems with Stems and Beams in the past I think it's an area of the
code that could be improved, because there is an effective circular
dependency:
- Stems check Beams in order to determine their direction/position etc
- Beams check where the first and last noteheads are - compared to the
whole system - to try and figure out on which side they should be on
or if the beam should be kneed, etc
- Checking where noteheads are in relation to the whole system triggers
lots of other grob calculations. If any of these calculations check
the Beam or the Stem you get a circular dependency (I fixed at least
one regression in this area where DynamicText was triggering the
circular dependency).
- If you try to dive into all the consequences of the code that
calculates a Stem's direction it is almost impossible to understand.
It's a long chain of pure/unpure calls - maybe 50 stack frames of just
that stuff (IIRC); completely impenetrable (for me at any rate)
- In my opinion, the fix is to find a way to figure out notehead
positions without calculating everything else, then Beams, then Stems
I doubt that is any help to you, but perhaps someone else will read this
and know more.
Kevin