Re: [Denemo-devel] Printing parts

[Richard Shann]

I've had a look at draw.c and the voicenumber==1 code is broken, I have
a fix (it has to look at curstaff->next to decide whether to increment
y, not at curstaff, since there can be many voicenumber==2)
Richard

> > I'll look at fixing the voice placing in exportlilypond.c: if I figure
> > anything out I will post it here.
> > Richard
> 
> I've had a look - as I thought it is horrible. The voices are
> represented as separate staffs with a tag (misleadingly called
> voicenumber, but it has only two values 1 or 2) to say whether it is a
> staff or a further voice for the staff earlier in the GList which was
> tagged voicenumber=1.
> So the GList of staffs is a mixture of staffs and voices with implicit
> rules about what the order means.
> We can either just patch this up: 
>       1) in exportlilypond we do not start a new \context for voices with
> voicenumber==2
>       2) in AddVoice we create a new staff and give it voicenumber=2, placing
> it after the last one (possibly still working, but could have been
> broken fixing the coredumps in create/delete staff)
>       3) in draw.c we keep the y-coordinate the same as the previous staff
> when it is a voicenumber==2 type (possibly still working, but could have
> been broken fixing the automatic height of staffs)
> 
> or we could fix it. The latter would mean replacing the measures field
> in Staff with a Voices GList whose elements were GLists of measures.
> Which would mean re-working the three elements described above. Plus of
> course, a currentvoice field in the staff and replacement of references
> to staff->measures by staff->currentvoice->measures. A lot more work,
> and I never use voices myself ... but a significant advance in the code.
> 
> I think it would be a mistake to delay a release while doing all that -
> and I think a release is urgent because the current code coredumps
> disconcertingly which is a real turn-off. We could just patch up for
> now. At least (if I've got it right) what is going on is documented in
> this email!
> 
> Richard
> 
> 
> 
>