lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Chords in LilyPond


From: Winston, Charles R.
Subject: Re: Chords in LilyPond
Date: Sun, 28 May 2017 18:08:51 +0000


> On May 28, 2017, at 12:55 PM, Kieren MacMillan <address@hidden> wrote:
> 
> 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?  =)

I see your points. My intention is definitely not to create a representation 
where the notes and semantics cannot be passed together into different 
contexts--I was just trying to make a point that it makes sense to keep the 
information separate within EventChord. Though, even though they will be 
separate entries in EventChord, that doesn't stop the possibility of using them 
together, does it?

Charles

reply via email to

[Prev in Thread] Current Thread [Next in Thread]