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