On Monday, 30 March 2015 at 10:35:13 am +0200, Élie Roux wrote: > I'm not sure I totally understand the problems you encountered, but if I > understood correctly, this is an inherent problem with the way gabc > builds internal structure of a syllable, by: > > * first building a list of notes, but with informations relative to glyphs > * then build the glyphs on top of the notes, moving glyph informations > contained in notes in the glyph themselves > * above all, the fact that some fields specific to some glyph types are > stored in fields where they don't belong in the first pass (typically > pitch for some bars) > > I think the cleanest solution to this would be to have a new type in the > first pass, that would be a union of note and glyph_level_infos, and > then build everything on top of that, but it's quite a lot of work... so > maybe a glyph_level_infos pointer in the gregorio_note structure that > would be NULL in the final structure but that would contain clean > glyph_level information in the first pass of gabc would be good? > > I'm not sure I managed to express myself correctly, tell me if it's too > blur (and if it relates at all to your problems). > gregorio_glyph.glyph_type is as much an offender as gregorio_note.pitch in terms of being a multi-purpose field.
My reason for the enum conversion was to make debugging easier (gdb will show the enum name rather than a number that needs to be looked up). Multi-purpose fields mean that you need to understand the context of the field in order to look up the value. Even if it were a union of enums, you'd still need to understand the context and remember how it should apply to understand the output. This is why I abandoned the union idea. The cleanest thing, from an understanding point-of-view, would be to have fields with a singular purpose in all the structures, but this makes the structures bulkier with unused fields. Since these structures hold the entire score, I think this is an acceptable size-leaning compromise, but a difficult barrier for a new developer to understand. If what I'm saying doesn't make sense, then maybe I didn't understand what you meant above. Henry _______________________________________________ Gregorio-devel mailing list [email protected] https://mail.gna.org/listinfo/gregorio-devel
