Le 08/04/2021 à 18:19, Thomas Morley a écrit :
Am Do., 8. Apr. 2021 um 16:21 Uhr schrieb Kevin Barry <[email protected]>:
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
Hi Kevin,
thanks for your reply.
You surely mean the position in x-axis direction for the NoteHeads!?
Best,
Harm
Hi,
In my understanding, the problem is with cross-staff
beams. When they try to determine whether they should
be kneed, they get the distance between the two staves,
which triggers VerticalAxisGroup extent calculations,
and those need estimates for all grobs they contain.
Consider:
<<
\new Staff = "up" \relative c'' {
a8 g f e d c \change Staff = "down" b a
}
\new Staff = "down" {
\clef bass
s1
}
>>
<<
\new Staff = "up" \relative c'' {
a8_\markup \column { big markup taking space } g f e d c\change
Staff = "down" b a
}
\new Staff = "down" {
\clef bass
s1
}
>>
Or did you observe the same phenomenon without cross-staff
beams, Kevin?
Regards,
Jean
