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. By the
way, are there architectural drawings for Denemo?
Andreas
