Re: [Denemo-devel] Tidying up the main structures

[Richard Shann]

On Mon, 2008-01-21 at 11:08 -0600, Jeremiah Benham wrote:
> On Mon, 2008-01-21 at 07:39 +0000, Richard Shann wrote:
> 
> > I propose to replace the global variable "displays" with a structure
> > DenemoRoot containing the list of DenemoGUI and the preferences. The
> > DenemoGUI corresponds to a Denemo file on disk as at present. It all the
> > GUI stuff together with stuff that applies to the whole piece of music -
> > a list of DenemoScore representing movements in the piece and the
> > DenemoScore si pointer to the current movement and the header data that
> > applies to the whole piece. The DenemoScore corresponds to a single
> > \score {} block in the output LilyPond, ie to a single movement (as at
> > present, but currently Denemo is limited to one movement).
> 
> This all sounds like a good idea.
> You say the header data applies to the whole piece? Don't you want it to
> print different titles for each movement. Maybe I am confused. 
most of it does but \piece goes with the movement. There is also scope
for \markup before and after movements. One of the nicest things is that
the page numbering is continuous throughout the piece of music. I
haven't experimented yet with page breaks - whether it has got easier
over the past few years (I've been busy for two or three years and not
done much LilyPond stuff).
> 
> On a similar subject I would soon like to fix some of the types used in
> the frequently used data structures. DenemoObject is on of the most
> frequently used. We have all these structure members defined with the
> type int or gint. We have basic_durinticks, durinticks, starttick,
> starttickofnextnote all defined as gint. I find it very unlikely that
> and of these variables will go below 0. I suggest we change everything
> that will always be >0 and does not need a decimal to be defined as
> guint, guint16, or guint8. I have also seen places where gint was the
> type defined for somethings that could have been gboolean. I think just
> fixing a few of these will have noticeable performance and memory
> improvements. I think this is something we should address fairly soon. 
I would suggest changing the types only for the purposes of improving
the readability of the code, I don't think you will ever notice anything
in performance or memory use (humans and music stay the same while the
memory & cpus carry on improving - twice as fast as a blink of an eye
is ... a blink of an eye :-)
I'm ready to go with the movements stuff - just testing...
best wishes,
Richard