On 5/28/17 5:53 PM, "Thomas Morley" <thomasmorle...@gmail.com> wrote:
> > >Though, why adding a Œsemantics entry to the EventChord? >I'd suggest to write such an interpreter as a procedure which works on >the pitchlist ignatzek-chord-names currently has to work with >(including bass/inversion-info). Then write a printing-function which >works on the result of the interpreter. >Both public in guile, so that users can write different interpreters >and printing-functions as they like. There are three different problems in the Chords construct. 1) How to input chords. We currently have two modes -- notemode and chordmode. Notemode has no semantics. Chordmode has semantics, but currently the semantics get largely tossed away (except for root, bass, inversion, IIRC). 2) How to determine a chord name. For this, we currently have ignatzek-chord-names which interprets the pitches plus root, bass, inversion into a chord name. 3) How to display a chord name. This is currently mixed up with the determination of a chord name in ignatzek-chord-names. Charles's project is not to solve all three of these. In fact, his project is not to completely solve any one of them. Rather, his problem is to determine how best to save the semantics, so that assuming the semantics are properly entered in chordmode (probably including some extensions to the current chordmode, or maybe even a start from scratch rewrite, but that's out of scope for this project), the semantics will be kept as part of the chord, and thus be available for the chord_name_engraver to use when generating a chord name. When Charles is done, I hope that we will have a good internal representation for both the notes and the semantics. The user will have the ability to define the semantics (at first, maybe only with Scheme, but eventually through good input). And those semantics will lead to the desired output. Right now, we don't have control of the semantics; they're inferred from the pitches. And that causes problems. Of course, we'll need to get good display routines (printing functions). And we'll need to get good input routines (for both chordmode and note mode). And we'll need to get good infer-semantics-from-pitches routines (which Harm calls interpreters, I believe). But if each of these can be separated from the others (which I hope Charles's project will do by capturing semantics properly in the EventChord structure), then I believe it will be easier to tackle all of the problems. Thanks, Carl _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
