Hi Shevek, > Well, it is part of the presentation layer, but the specific decision of how > to combine parts in a particular passage depends on what the music is. If I > decide one to day to change a unison passage to octaves, then the next to > make it solo, and after that to make it dovetail contrapuntally, those > musical content changes all directly affect how the parts should be combined > on a staff or not. Abstracting the decision to combine or not would mean I > need to look in two places in the code to understand what's happening there. > > I see it as similar to modifying the shape of a slur. It's purely > presentational, but it depends directly on the musical content, so I would > find it rather confusing to put the override in a separate part of the code > from the notes.
Ah, I understand. Yes, different ways of working with Lilypond definitely work more or less well depending on which hat I'm wearing at a given time (composer, arranger, orchestrator, or engraver). That's why I try, if at all possible, to avoid even cracking Lilypond open until I'm converging on the final engraving: at that point, I can enter all the musical content (notes, dynamics, curves, text, etc.) at a single go, and then turn my attention entirely to the presentation layer (which lives in a single, but separate, part of the file-set). On the rare occasion I need to bounce back and fix something in the content code, Frescobaldi's shortcuts make it dead simple to do so. Anyway, thanks for letting me know about your combining/splitting process/mechanism — it will be a useful addition to the document I'm putting together. Cheers, Kieren. ________________________________ Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
