On Sun, 2026-02-01 at 10:05 +0100, Andreas Schneider wrote: > Am 27.01.26 um 18:48 schrieb Richard Shann: > > On Sat, 2026-01-24 at 19:49 +0100, Andreas Schneider wrote: > > > Hi Richard, > > > > > > Could you please give a short introduction into the C code that > > > handles > > > the Denemo measures? > > > > sorry for the delay in replying, nothing sprang to mind when you > > asked > > this, I don't hold this stuff in my head: I tend to start from some > > command script that seems relevant and trace its origin in > > src/scripting/scheme-callbacks.c back to the C-code it calls. I see > > functions manipulating the measures in src/command/measure.c while > > the > > objects in the measures are manipulated in src/command/object.c. > > (The > > data structures are defined in include/denemo/denemo_types.h - in > > the > > case of the measures they are a field in the DenemoStaff structure: > > > > measurenode *themeasures; /**< This is a GList of DenemoMeasure > > objects */ > > > > with the DenemoMeasure structure containing DenemoObjects) > > > > The code dates back to 1999 and shows it (measurenode* mentioned > > above > > is as I recall just a GList* following some notion of making the > > code > > more readable...), moving an object from one measure to another > > could > > have complications that have been worked around in the > > implementation > > of cut and paste - I'm pretty sure that if you simply lifted an > > object > > out of one GList and put it in another there would be chaos; as it > > is, > > I noticed the other day there is still a bug with the display on > > doing > > something along those lines, the objects are drawn wrongly with the > > cursor jumping back and forth as you advance over them with the > > cursor > > keys. > > Thank you very much for the explanations and sorry for the delayed > reply. I have now found the time to look at the code. It turns out > that > the implementation of an auto-measure feature seems much more tricky > and > complicated than I imagined, especially due to the side-effects you > have > named. There are a lot of pointers, and I can imagine some may easily > become outdated if you don't pay attention. The internal structure > might > be modernised, e.g. using modern C++ and STL container. For measures > to > automatically adjust themselves, an internal structure holding all > objects in the staff and having barline objects that move around > would > be better suited. However, such a fundamental refactoring would be a > huge effort and probably come with quite some risk. It is not a > first-time task and would take much more time than I can spend.
yes. > By the > way, are there architectural drawings for Denemo? no I'm sure there isn't, but it has struck me that it may be possible (soon?) to use AI to create something that could swallow the entire code and answer questions about it ... indeed point out things that could be fixed. (I noticed the other day a comment in the code asking "is this thread safe?" which has remained unanswered since I wrote it). Richard
