Hi Charles (et al.),
> Storing this information in the NoteEvents is clunky in my opinion
Possibly…
> and defeats the purpose of this project
I don’t see how that necessarily/logically follows…?
> the numerous benefits of an internal representation which understands the
> semantics of a chord beyond its notes.
This would clearly be a great and useful step forward from what we currently
have.
> the contexts that need the semantic information shouldn’t need note
> information, and the contexts that need note information don’t need semantic
> information.
As someone who uses chords both for their note and semantic information
simultaneously, I would disagree. David’s example
> \new ChordNames \fixed c' { <c e g> <f a c'> <g b d'> <c e g> }
perfectly illustrates how note and semantic information should be seamlessly
swapped back and forth across any and all possible contexts. I tried to hint at
this when I posted (earlier in this thread) about storing voicing information
in the chord code — if I write
explicitChords = \fixed c’ { <c e g’''> <f a, c'> <g b'' d'> <c e g’> }
and then use
<<
\new ChordNames \explicitChords
\new Staff \explicitChords
>>
what I see (in both contexts) should be what I expect: the ChordNames output
according to my settings/preferences, and the Staff showing the notes *with the
voicings I coded*.
The difficult part, of course, is figuring out how to provide this
functionality with a reasonably consistent, compact, and intuitive input method
and throughput (internal) representation. But that’s what your GSoC project is
all about, right? =)
Best,
Kieren.
________________________________
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [email protected]
_______________________________________________
lilypond-user mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user
