Chords in LilyPond

classic Classic list List threaded Threaded
81 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Chords in LilyPond

Charles Winston
Hi LilyPond users,

I’m participating in the Google Summer of Code working on improving LilyPond’s internal representation of chords. The goal here is to create a data structure that will represent a chord’s semantics beyond just a list of notes in the chord. The current representation contains almost no information other than a list of notes, and we want to change this to include other semantic information, i.e. the root, quality, extensions. The current representation causes the chord naming process to infer the correct name from only the notes in the chord, which can create some problems—it would be much better to maintain the information provided by the user in chord mode about the semantics of the chord through to the naming process. Here is a rough list of semantic information I believe should be included in the data structure:

        root note
        quality (major, minor, augmented, diminished)
        extension (7, 9, 11, 13, etc.)
        added notes (6, 9, etc.)
        suspensions (sus4, sus2, etc.)
        alterations (flat-5, sharp-9, etc.)
        omitted notes
        added bass note
        inversions

Some things that should be thought about:

        Is the 7 an extension? Or included in the quality the chord? Or maybe something else?
        How do we deal with semantics that may overlap between these categories? For example: is a sharp-5 an alteration or just an augmented chord?
        What else do we want to include? This list certainly isn’t exhaustive. We probably want to support more complete chord structures, one example being polytonal/stacked chords (like Cmaj / Bbmaj). One issue is that these complex structures have a higher degree of ambiguity and can often be names in multiple different ways. This is something that should be addressed.

I would love to hear any ideas from the user community about this. And beyond the specific issues I’m talking about here, what aspects of LilyPond’s support for chords do you believe should be improved or changed?

I hope many of you are excited about this conversation. I am certainly excited to start working on it!

Best,
Charles Winston
_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Kieren MacMillan-2
Hello Charles,

> I’m participating in the Google Summer of Code working on improving LilyPond’s internal representation of chords.

As someone who uses chord names extensively, I’m thrilled that you’re tackling this!

> The goal here is to create a data structure that will represent a chord’s semantics beyond just a list of notes in the chord.

Excellent goal!

> it would be much better to maintain the information provided by the user in chord mode about the semantics of the chord through to the naming process.

Agreed.

> Here is a rough list of semantic information I believe should be included in the data structure:
> root note
> quality (major, minor, augmented, diminished)
> extension (7, 9, 11, 13, etc.)
> added notes (6, 9, etc.)
> suspensions (sus4, sus2, etc.)
> alterations (flat-5, sharp-9, etc.)
> omitted notes
> added bass note
> inversions

Yes.

> Some things that should be thought about:
> Is the 7 an extension? Or included in the quality the chord? Or maybe something else?

Since we’re starting from the ground up, can we not assume triadic harmony for the input (even if the output makes it look like we do)? For example, <c f bf> is not really, to my ears, a triadic chord with extensions and suspensions, but rather a quartic “triad”. Maybe there’s a way to handle this kind of thing (and others) elegantly?

> How do we deal with semantics that may overlap between these categories? For example: is a sharp-5 an alteration or just an augmented chord?

A difficult question. Obviously, it would be great to allow the user — at the input, throughput, and output stages — to decide how to handle the information.

> polytonal/stacked chords (like Cmaj / Bbmaj)

Yes, please!

> I would love to hear any ideas from the user community about this. And beyond the specific issues I’m talking about here, what aspects of LilyPond’s support for chords do you believe should be improved or changed?

Here’s one off the top of my head: I would love to be able to easily input/output something like

  C    /B    /Bb

I’d add more now, but I’ve got to go to see some new opera.  =)

> I hope many of you are excited about this conversation.

I sure am! Please feel free to contact me on- or off-list with any questions.

Best,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Simon Albrecht-2
In reply to this post by Charles Winston
Am 25.05.2017 um 00:17 schrieb Charles Winston:
> added bass note
> inversions

I’m under the impression that in chord notation those are actually the
same – I don’t think that there is a conceptual difference between C/E
and C/D in chord notation. But it may be that instead of this pragmatic
way to understand chord notation some have a more theoretical/analytical
use of them?
I think unless you intend to make the code usable for other kinds of
analysis (like functional analysis, or analysis with scale degrees –
which don’t yet have a dedicated input mode in LilyPond) there is no
need for a distinction between those two.

Best, Simon

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Simon Albrecht-2
In reply to this post by Charles Winston
Am 25.05.2017 um 00:17 schrieb Charles Winston:
> How do we deal with semantics that may overlap between these categories? For example: is a sharp-5 an alteration or just an augmented chord?

Off the top of my head: Both should be possible input methods, but
internally represented the same. How about having (amongst others) the
following distinct properties (just a sketch):

alteration of 3 (major, minor, none)
alteration of 5 (diminished, pure, augmented, none)
extension (default 5, or 7, 9, 11, …)
alterations (list of optional values, like 7+, 9-)

Best, Simon

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Thomas Morley-2
In reply to this post by Charles Winston
2017-05-25 0:17 GMT+02:00 Charles Winston <[hidden email]>:

> Hi LilyPond users,
>
> I’m participating in the Google Summer of Code working on improving LilyPond’s internal representation of chords. The goal here is to create a data structure that will represent a chord’s semantics beyond just a list of notes in the chord. The current representation contains almost no information other than a list of notes, and we want to change this to include other semantic information, i.e. the root, quality, extensions. The current representation causes the chord naming process to infer the correct name from only the notes in the chord, which can create some problems—it would be much better to maintain the information provided by the user in chord mode about the semantics of the chord through to the naming process. Here is a rough list of semantic information I believe should be included in the data structure:
>
>         root note
>         quality (major, minor, augmented, diminished)
>         extension (7, 9, 11, 13, etc.)
>         added notes (6, 9, etc.)
>         suspensions (sus4, sus2, etc.)
>         alterations (flat-5, sharp-9, etc.)
>         omitted notes
>         added bass note
>         inversions


Hi Charles,

I've not yet fully understood what "internal representation of chords" means.

Consider the following example, where I display the arguments which
our current ChordName-printing-function (ignatzek-chord-names) has to
work with:

\layout {
  \context {
        \Score
        chordNameFunction =
          #(lambda (chord-pitches additional-bass inversion-bass context)
            (newline)
            (format #t "chord-pitches:\n~y" chord-pitches)
            (format #t "additional-bass: ~y" additional-bass)
            (format #t "inversion-bass: ~y" inversion-bass)
            (format #t "context: ~a" context)
            (newline)
            (ignatzek-chord-names
              chord-pitches additional-bass inversion-bass context))
  }
}

mus =
\chordmode {
  c:9/e  %% inversion
  c:9/+e %% added bass
  c:9/d  %% inversion
  c:9/+d %% added bass
}

<<
  \new ChordNames \mus
  \new Staff \mus
>>

As an example I c/p the output for the last chord:

chord-pitches:
(#<Pitch c' >
 #<Pitch e' >
 #<Pitch g' >
 #<Pitch bes' >
 #<Pitch d'' >)
additional-bass: #<Pitch d >
inversion-bass: ()
context: #<Context ChordNames () >

So we already identify inversion/additional bass. And in
ignatzek-chord-names the first pitch of "chord-pitches" is taken as
root. Other procedures there try to distribute the remaining pitches
to what is currently called "prefixes", "main-name", "alterations",
"add-steps". "suffixes"



Am I correct assuming you want to have something at the lines of:

((root . <root-pitch>
 (quality . <one-of-major-minor-augmented-diminished>)
 (extension . <extension-pitches>)
 (added-notes . <added-pitches>)
 (suspensions . <suspended-pitches>)
 (alterations . <alterated-pitches>)
 (omitted-notes . <omittes-pitches>)
 (additional-bass . <additional-bass-pitch>)
 (inversion-bass . <inversion-bass>))

internally (i.e. C++) preprocessed from the pitches a user entered
while typing p.e. c:9/d to be delivered to the chordNameFunction?

Cheers,
  Harm

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Thomas Morley-2
In reply to this post by Simon Albrecht-2
2017-05-25 0:54 GMT+02:00 Simon Albrecht <[hidden email]>:

> Am 25.05.2017 um 00:17 schrieb Charles Winston:
>>
>> added bass note
>> inversions
>
>
> I’m under the impression that in chord notation those are actually the same
> – I don’t think that there is a conceptual difference between C/E and C/D in
> chord notation. But it may be that instead of this pragmatic way to
> understand chord notation some have a more theoretical/analytical use of
> them?
> I think unless you intend to make the code usable for other kinds of
> analysis (like functional analysis, or analysis with scale degrees – which
> don’t yet have a dedicated input mode in LilyPond) there is no need for a
> distinction between those two.
>
> Best, Simon



I disagree.
Currently
\chordmode { c/e c/+e }
prints the same: C/E
But in a Staff-context the pitches are different, (and likely in midi,
although I did not verify).
I wouldn't want to miss this, so the chordNameFunction has to deal
with those different bass-pitches.

Cheers,
  Harm

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Thomas Morley-2
In reply to this post by Charles Winston
2017-05-25 0:17 GMT+02:00 Charles Winston <[hidden email]>:

> I would love to hear any ideas from the user community about this. And beyond the specific issues I’m talking about here, what aspects of LilyPond’s support for chords do you believe should be improved or changed?

I think the greatest problem is the current difficulty to change the
chord-name-printing slightly (in details) or general.

Once I tried to get Brandt-Roemer namings. The criteria which pitches
are regarded to set extensions, etc are different enough from Ignatzek
that it would have resulted in a complete rewrite of the
chord-naming-procedure. Nothing what we could expect from an average
user.
But even for slight changes one would need to rewrite the procedure in
many cases. Ofcourse with a lot of copy'n paste but it is always
pretty tedious.

Would be great to offer the user an easy way to do so.
Though, as I mentioned above Brandt-Roemer have a different opinion,
what is an extension, etc compared to Ignatzek.
So it might be very tricky to get the "internal chord representation"
correct, (If I understood it correctly, at all ...)
to offer the posibility for the user to switch between different
chord-layouts as he may like.


Cheers,
  Harm

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

mskala
In reply to this post by Charles Winston
On Wed, 24 May 2017, Charles Winston wrote:
> I’m participating in the Google Summer of Code working on improving LilyPond’s internal representation of chords. The goal here is to create a data structure that will represent a chord’s semantics beyond just a list of notes in the chord. The current representation contains almost no information other than a list of notes, and we want to change this to include other semantic information, i.e. the root, quality, extensions. The current representation causes the chord naming process to infer the correct name from only the notes in the chord, which can create some problems—it would be much better to maintain the information provided by the user in chord mode about the semantics of the chord through to the naming process. Here is a rough list of semantic information I believe should be included in the data structure:

Correctly printing chord names - and specifically "Why doesn't the output
match what I typed?" - is a huge problem for users, and is a recurring
thread on this list, so I certainly think improvements there would be a
good thing.

What I think is most needed is a chord-naming mode that *just prints what
the user typed*, formatted with the fonts, spacing, and so on that we
expect for chord names - not translating it to an "internal
representation" of notes plus extra data as LilyPond "music" at all.  But
I was shouted down last time I proposed that, I think by people who
thought I had claimed it would solve all possible obscure problems for
imaginable hypothetical users.  As I made clear, it would only solve the
main problem of 99% of relevant users who actually exist, and that wasn't
enough to satisfy the list.

Failing a direct "print what I typed" mode, adding a lot of extra data to
the internal representation while keeping the current framework is the
hard way to get the input to match the output, but it'd be an improvement
and we need an improvement.

--
Matthew Skala
[hidden email]                 People before principles.
http://ansuz.sooke.bc.ca/
_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Winston, Charles R.


> On May 24, 2017, at 9:40 PM, "[hidden email]" <[hidden email]> wrote:
>
>> On Wed, 24 May 2017, Charles Winston wrote:
>> I’m participating in the Google Summer of Code working on improving LilyPond’s internal representation of chords. The goal here is to create a data structure that will represent a chord’s semantics beyond just a list of notes in the chord. The current representation contains almost no information other than a list of notes, and we want to change this to include other semantic information, i.e. the root, quality, extensions. The current representation causes the chord naming process to infer the correct name from only the notes in the chord, which can create some problems—it would be much better to maintain the information provided by the user in chord mode about the semantics of the chord through to the naming process. Here is a rough list of semantic information I believe should be included in the data structure:
>
> Correctly printing chord names - and specifically "Why doesn't the output
> match what I typed?" - is a huge problem for users, and is a recurring
> thread on this list, so I certainly think improvements there would be a
> good thing.
>
> What I think is most needed is a chord-naming mode that *just prints what
> the user typed*, formatted with the fonts, spacing, and so on that we
> expect for chord names - not translating it to an "internal
> representation" of notes plus extra data as LilyPond "music" at all.  But
> I was shouted down last time I proposed that, I think by people who
> thought I had claimed it would solve all possible obscure problems for
> imaginable hypothetical users.  As I made clear, it would only solve the
> main problem of 99% of relevant users who actually exist, and that wasn't
> enough to satisfy the list.
>
> Failing a direct "print what I typed" mode, adding a lot of extra data to
> the internal representation while keeping the current framework is the
> hard way to get the input to match the output, but it'd be an improvement
> and we need an improvement.
>
> --
> Matthew Skala
> [hidden email]                 People before principles.
> http://ansuz.sooke.bc.ca/
> _______________________________________________
> lilypond-user mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-user

Yes, we certainly want the output to match the input. This project strives to achieve that. We still need some data structure that can represent that input from chord mode and be understood by the chord name engraver--this I call the internal representation. The question we should be asking is: how much should we base this data structure on the current mode of input? Maybe we should base it on the current abilities of chordmode completely, but I believe certain aspects of input can be improved as well, and we may want to use this project now to create an exhaustive list of characteristics of chords users that might not yet be supported by chord mode.

Thanks,
Charles
_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Kieren MacMillan
In reply to this post by Simon Albrecht-2
Hi Simon (et al.),

>> added bass note
>> inversions
> I’m under the impression that in chord notation those are actually the same

Definitely not! What if I want a C7 in second inversion over a Db? In pseudo-harmonic-analysis code, that would be

   C4/3  / Db

In my compositions (especially musical theatre and concert drama), I use that kind of construction all the time — but I end up having to dumb down the chord names in my scores, because Lily doesn’t let me put exactly what I want.

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Kieren MacMillan
In reply to this post by Thomas Morley-2
Hi Harm,

> Once I tried to get Brandt-Roemer namings.

Have you seen my B-R stylesheet? It’s almost a complete representation.

> The criteria which pitches are regarded to set extensions, etc are different enough from Ignatzek
> that it would have resulted in a complete rewrite of the chord-naming-procedure.

Yes, there are a few things that require serious hacking.  =(

Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Kieren MacMillan
In reply to this post by mskala
Hi Matthew (et al.),

> What I think is most needed is a chord-naming mode that *just prints what
> the user typed*, formatted with the fonts, spacing, and so on that we
> expect for chord names - not translating it to an "internal
> representation" of notes plus extra data as LilyPond "music" at all.

I agree that there should be a “markup mode”, so that the user can type what they want — despite the fact that they’ll be shooting themselves in the foot regarding code reuse (e.g., transposition).

> I was shouted down last time I proposed that, I think by people who
> thought I had claimed it would solve all possible obscure problems for
> imaginable hypothetical users.  As I made clear, it would only solve the
> main problem of 99% of relevant users who actually exist, and that wasn't
> enough to satisfy the list.

Um… wow… just… wow.

Kieren.

________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Kieren MacMillan
In reply to this post by Winston, Charles R.
Hi Charles,

> we certainly want the output to match the input.

An important question is: is it a one-to-one relationship?

> how much should we base this data structure on the current mode of input?

Which mode of input?

    \chordmode { c1:7 }

or

    { <c' e' g' bf'>1 }

??

> certain aspects of input can be improved as well

Definitely.

> we may want to use this project now to create an exhaustive list of characteristics of chords users that might not yet be supported by chord mode.

Definitely. Even if you don’t get around to implementation of some of them, to have planned ahead for them is essential.

Thanks,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Winston, Charles R.


On May 25, 2017, at 12:09 AM, Kieren MacMillan <[hidden email]> wrote:

>> how much should we base this data structure on the current mode of input?
>
> Which mode of input?
>
>    \chordmode { c1:7 }
>
> or
>
>    { <c' e' g' bf'>1 }

I think \chordmode will be the most useful form of input, because that way we know the user's intentions with the chords. It would be tough to infer the semantics from just the note input, which is essentially what happens now with the current naming process (which is what we are trying to fix)

Charles
_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Kieren MacMillan
Hi Charles,

>> Which mode of input?
>>   \chordmode { c1:7 }
>> or
>>   { <c' e' g' bf'>1 }
>
> I think \chordmode will be the most useful form of input, because that way we know the user's intentions with the chords. It would be tough to infer the semantics from just the note input, which is essentially what happens now with the current naming process (which is what we are trying to fix)

Except <e bf g’ c''> contains a huge amount of information that cannot currently be input in \chordmode (as far as I know).

Ultimately, as long as we end up with an input system robust enough to convey that amount of information, I don’t particularly care whether it’s in \chordmode or whatever.

Thanks,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Charles Winston

> On May 25, 2017, at 12:26 AM, Kieren MacMillan <[hidden email]> wrote:
>
> Hi Charles,
>
>>> Which mode of input?
>>>  \chordmode { c1:7 }
>>> or
>>>  { <c' e' g' bf'>1 }
>>
>> I think \chordmode will be the most useful form of input, because that way we know the user's intentions with the chords. It would be tough to infer the semantics from just the note input, which is essentially what happens now with the current naming process (which is what we are trying to fix)
>
> Except <e bf g’ c''> contains a huge amount of information that cannot currently be input in \chordmode (as far as I know).
>
> Ultimately, as long as we end up with an input system robust enough to convey that amount of information, I don’t particularly care whether it’s in \chordmode or whatever.

True. I think ideally we need an input mode that is stronger than chordmode, or we at least need to improve chordmode to be able to handle complex structures like your example. I think the best thing to do is base many of the semantic categories off of existing features supported by chordmode, as well as add additional categories that are not yet supported by any input mode, the hope being that a follow-up to this project can tackle the improvement of the input.

Charles

>
> Thanks,
> Kieren.
> ________________________________
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: [hidden email]
>
>
> _______________________________________________
> lilypond-user mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-user


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

mskala
On Thu, 25 May 2017, Charles Winston wrote:

> > On May 25, 2017, at 12:26 AM, Kieren MacMillan
> > <[hidden email]> wrote: Except <e bf g’ c''> contains a
> > huge amount of information that cannot currently be input in
> > \chordmode (as far as I know).
> >
> > Ultimately, as long as we end up with an input system robust enough to
> > convey that amount of information, I don’t particularly care whether
> > it’s in \chordmode or whatever.
>
> True. I think ideally we need an input mode that is stronger than
> chordmode, or we at least need to improve chordmode to be able to handle
This is why I think the chord names -> music -> chord names flow is a
problem.  Real users do not think in terms of a translation from input to
notes and then from notes to output; as seen in the recurring threads on
this mailing list, most non-expert users don't even realize that "chord
mode" and the "ChordNames context" are two different things that do not
necessarily always go together.  The natural way for typesetting of chord
names to occur is by a direct mapping from input chord names to output
chord names without going through the current "music" data struture
consisting of notes, at all.

--
Matthew Skala
[hidden email]                 People before principles.
http://ansuz.sooke.bc.ca/
_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Mats Behre-3
On 2017-05-25 06:52, [hidden email] wrote:

> On Thu, 25 May 2017, Charles Winston wrote:
>>> On May 25, 2017, at 12:26 AM, Kieren MacMillan
>>> <[hidden email]> wrote: Except <e bf g’ c''> contains a
>>> huge amount of information that cannot currently be input in
>>> \chordmode (as far as I know).
>>>
>>> Ultimately, as long as we end up with an input system robust enough to
>>> convey that amount of information, I don’t particularly care whether
>>> it’s in \chordmode or whatever.
>> True. I think ideally we need an input mode that is stronger than
>> chordmode, or we at least need to improve chordmode to be able to handle
> This is why I think the chord names -> music -> chord names flow is a
> problem.  Real users do not think in terms of a translation from input to
> notes and then from notes to output; as seen in the recurring threads on
> this mailing list, most non-expert users don't even realize that "chord
> mode" and the "ChordNames context" are two different things that do not
> necessarily always go together.  The natural way for typesetting of chord
> names to occur is by a direct mapping from input chord names to output
> chord names without going through the current "music" data struture
> consisting of notes, at all.
>
While this is true, in order to support things like transposition (which I for one use frequently) I think you will have to devise formats for input and internal representation (they may be the same) that identifies both all aspects of the chord and the specified notes (in this respect I only consider the root note of a triad a 'specified note', but that will be up to the format, really). If you are able to achieve that for all conceivable chords (i.e. the format has open-ended enough for the user to add notes) it should be possible to specify how each combination should be output, and usually for print this will strongly reflect the way the chord is entered, but the output media could also be e.g. MIDI. (No, I don't think this will necessarily be easy ...)

Even though the average user doesn't think of an intermediate representation a program that can do manipulations still needs a representation it can work with.

Mats


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Thomas Morley-2
In reply to this post by Kieren MacMillan
2017-05-25 6:00 GMT+02:00 Kieren MacMillan <[hidden email]>:
> Hi Harm,
>
>> Once I tried to get Brandt-Roemer namings.
>
> Have you seen my B-R stylesheet? It’s almost a complete representation.

Hi Kieren,

I don't have it stored here, but seem to remember having seen it on
the list here some time ago.
Am I correct you did all by chord-exceptions?

Cheers,
  Harm

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Chords in LilyPond

Thomas Morley-2
In reply to this post by mskala
Hi Matthew,

2017-05-25 3:39 GMT+02:00  <[hidden email]>:
> On Wed, 24 May 2017, Charles Winston wrote:
>> I’m participating in the Google Summer of Code working on improving LilyPond’s internal representation of chords. The goal here is to create a data structure that will represent a chord’s semantics beyond just a list of notes in the chord. The current representation contains almost no information other than a list of notes, and we want to change this to include other semantic information, i.e. the root, quality, extensions. The current representation causes the chord naming process to infer the correct name from only the notes in the chord, which can create some problems—it would be much better to maintain the information provided by the user in chord mode about the semantics of the chord through to the naming process. Here is a rough list of semantic information I believe should be included in the data structure:
>
> Correctly printing chord names - and specifically "Why doesn't the output
> match what I typed?" - is a huge problem for users, and is a recurring
> thread on this list, so I certainly think improvements there would be a
> good thing.

I vaguely remember such threads.
Though, could you give some examples (or links) so it is present here as well?

>
> What I think is most needed is a chord-naming mode that *just prints what
> the user typed*, formatted with the fonts, spacing, and so on that we
> expect for chord names

Well, that's one of the major problems.
There seems to be no "we", even my expectations may differ from yours.

And a chord-naming mode that *just prints what the user typed* is
currently not specific enough for me.
Could you give a pseudo-code-example demonstrating something for which
current LilyPond fails?

Something at the line of

\new ChordNames \chord-input-mode { c7/des }
-> C⁷/D♭

This is not a good example, because current LilyPond can do this
without problems:
\new ChordNames \chordmode { c1:7/des  }
But you may get what I mean.


Cheers,
  Harm

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
12345