Re: Improve internal chord structure

[Urs Liska]

Am 03.04.2017 um 20:05 schrieb Renato Fabbri:
> ok, I revised the proposal:
> https://docs.google.com/document/d/1aGLfUGgbfV4_izmALUcb0UGQ3k4t-5tOb6rUFNnEIqc/edit?usp=sharing
> it is better now with many writing corrections but also with some better
> exposition of ideias.
> All the changes were minor, but if you know a way for us to upload this
> updated version of the proposal,
> it might be .worth it.

The GSoC program rules explicitly state that we must not consider any
changes applied to the draft document but base our judgment on the final
PDF version.

This is not to say that the potential mentor will not be influenced by
such changes ;-)

Urs

>
> Best,
>
> On Mon, Apr 3, 2017 at 1:05 PM, Renato Fabbri 
> wrote:
>
>> I took all your observations in account (thanks!) and wrote a proposal:
>> https://docs.google.com/document/d/1aGLfUGgbfV4_izmALUcb0UGQ3k4t-
>> 5tOb6rUFNnEIqc/edit?usp=sharing
>> It is submitted to the GSoC interface.
>> Is closing time for the proposals, so I should only be able to enhance
>> this draft.
>> I should read it again soon and make minor corrections, for example.
>>
>> Best and Thanks once more!
>>
>> On Mon, Apr 3, 2017 at 6:18 AM, David Kastrup  wrote:
>>
>>> Carl Sorensen  writes:
>>>
 On 4/2/17 1:13 AM, "lilypond-devel on behalf of Renato Fabbri"
  wrote:

> Ok, I looked through the LilyPond code.
>
> Notes:
> *) There seems to be some emphasis on the perspective given in the book
> Die Jazzmethode fuer Klavier 1 (Klaus Ignatzek).
> Can someone send me a PDF of this book or know how can I find
> an online copy at least of the most important parts for this case?
 I do not have a PDF or a reference.  But I think that the emphasis on
 Ignatzek need not be exclusive. That is, Ignatzek has a point of view on
 chords.  So do Brandt and Roemer.  Lilypond should be able to support
 anybody's view, not just one person's.

> *) Just so I (and other proponents) get it very clear, what do we need
> beyond our current capability exposed in the snippet:
> http://git.savannah.gnu.org/cgit/lilypond.git/tree/
> Documentation/snippets/chord-name-exceptions.ly
 This capability reflects the current state of LilyPond's chord naming
 structure, which is to try to guess the name of the chord by analyzing
 pitches.  So if you want to define a new chord name, you do it by
 defining the list of pitches in the chord.  It's doable, but the chord
 itself doesn't carry any semantic information.
>>> Except when it does.  Music properties "inversion", "octavation", "bass"
>>> carry semantic information beyond the chord pitch.
>>>
 The proposal is to put the necessary information describing the
 semantics of the chord in the chord itself, rather than trying to
 recreate it from the notes present in the chord.
>>> I am not saying that the current semantic information attached to chords
>>> by the \chordmode parser is suitable for all purposes and/or
>>> defined/utilized/documented to the best possible degree.
>>>
>>> But ignoring it would make for an awkward start.
>>>
 Here's an old proposal that never made it to application:
 https://lists.gnu.org/archive/html/lilypond-user/2009-01/msg00897.html

 Here's an interesting discussion on chord names that addresses a
>>> suspended
 chord:
 https://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00864.html

 Here's another thread that shows problems with chord naming:
 https://lists.gnu.org/archive/html/lilypond-user/2008-02/msg00391.html

 Here's an email discussing another possible benefit of the approach:
 https://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00155.html

 And another discussion of some of the challenges:
 https://lists.gnu.org/archive/html/lilypond-devel/2002-05/msg00069.html

 Here's one that actually started the thinking for the GSOC project:
 https://lists.gnu.org/archive/html/lilypond-user/2014-12/msg00617.html

 Somehow the last thread got broken; here's the follow up:
 https://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00065.html

 I hope this is helpful.
>>> Certainly something to look through.
>>>
>>> --
>>> David Kastrup
>>>
>>
>>
>> --
>> Renato Fabbri
>> GNU/Linux User #479299
>> labmacambira.sourceforge.net
>>
>
>

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[Renato Fabbri]

ok, I revised the proposal:
https://docs.google.com/document/d/1aGLfUGgbfV4_izmALUcb0UGQ3k4t-5tOb6rUFNnEIqc/edit?usp=sharing
it is better now with many writing corrections but also with some better
exposition of ideias.
All the changes were minor, but if you know a way for us to upload this
updated version of the proposal,
it might be .worth it.

Best,

On Mon, Apr 3, 2017 at 1:05 PM, Renato Fabbri 
wrote:

> I took all your observations in account (thanks!) and wrote a proposal:
> https://docs.google.com/document/d/1aGLfUGgbfV4_izmALUcb0UGQ3k4t-
> 5tOb6rUFNnEIqc/edit?usp=sharing
> It is submitted to the GSoC interface.
> Is closing time for the proposals, so I should only be able to enhance
> this draft.
> I should read it again soon and make minor corrections, for example.
>
> Best and Thanks once more!
>
> On Mon, Apr 3, 2017 at 6:18 AM, David Kastrup  wrote:
>
>> Carl Sorensen  writes:
>>
>> > On 4/2/17 1:13 AM, "lilypond-devel on behalf of Renato Fabbri"
>> > > > renato.fab...@gmail.com> wrote:
>> >
>> >>Ok, I looked through the LilyPond code.
>> >>
>> >>Notes:
>> >>*) There seems to be some emphasis on the perspective given in the book
>> >>Die Jazzmethode fuer Klavier 1 (Klaus Ignatzek).
>> >>Can someone send me a PDF of this book or know how can I find
>> >>an online copy at least of the most important parts for this case?
>> >
>> > I do not have a PDF or a reference.  But I think that the emphasis on
>> > Ignatzek need not be exclusive. That is, Ignatzek has a point of view on
>> > chords.  So do Brandt and Roemer.  Lilypond should be able to support
>> > anybody's view, not just one person's.
>> >
>> >>
>> >>*) Just so I (and other proponents) get it very clear, what do we need
>> >>beyond our current capability exposed in the snippet:
>> >>http://git.savannah.gnu.org/cgit/lilypond.git/tree/
>> >>Documentation/snippets/chord-name-exceptions.ly
>> >
>> > This capability reflects the current state of LilyPond's chord naming
>> > structure, which is to try to guess the name of the chord by analyzing
>> > pitches.  So if you want to define a new chord name, you do it by
>> > defining the list of pitches in the chord.  It's doable, but the chord
>> > itself doesn't carry any semantic information.
>>
>> Except when it does.  Music properties "inversion", "octavation", "bass"
>> carry semantic information beyond the chord pitch.
>>
>> > The proposal is to put the necessary information describing the
>> > semantics of the chord in the chord itself, rather than trying to
>> > recreate it from the notes present in the chord.
>>
>> I am not saying that the current semantic information attached to chords
>> by the \chordmode parser is suitable for all purposes and/or
>> defined/utilized/documented to the best possible degree.
>>
>> But ignoring it would make for an awkward start.
>>
>> > Here's an old proposal that never made it to application:
>> > https://lists.gnu.org/archive/html/lilypond-user/2009-01/msg00897.html
>> >
>> > Here's an interesting discussion on chord names that addresses a
>> suspended
>> > chord:
>> > https://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00864.html
>> >
>> > Here's another thread that shows problems with chord naming:
>> > https://lists.gnu.org/archive/html/lilypond-user/2008-02/msg00391.html
>> >
>> > Here's an email discussing another possible benefit of the approach:
>> > https://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00155.html
>> >
>> > And another discussion of some of the challenges:
>> > https://lists.gnu.org/archive/html/lilypond-devel/2002-05/msg00069.html
>> >
>> > Here's one that actually started the thinking for the GSOC project:
>> > https://lists.gnu.org/archive/html/lilypond-user/2014-12/msg00617.html
>> >
>> > Somehow the last thread got broken; here's the follow up:
>> > https://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00065.html
>> >
>> > I hope this is helpful.
>>
>> Certainly something to look through.
>>
>> --
>> David Kastrup
>>
>
>
>
> --
> Renato Fabbri
> GNU/Linux User #479299
> labmacambira.sourceforge.net
>



-- 
Renato Fabbri
GNU/Linux User #479299
labmacambira.sourceforge.net
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[Renato Fabbri]

I took all your observations in account (thanks!) and wrote a proposal:
https://docs.google.com/document/d/1aGLfUGgbfV4_izmALUcb0UGQ3k4t-5tOb6rUFNnEIqc/edit?usp=sharing
It is submitted to the GSoC interface.
Is closing time for the proposals, so I should only be able to enhance this
draft.
I should read it again soon and make minor corrections, for example.

Best and Thanks once more!

On Mon, Apr 3, 2017 at 6:18 AM, David Kastrup  wrote:

> Carl Sorensen  writes:
>
> > On 4/2/17 1:13 AM, "lilypond-devel on behalf of Renato Fabbri"
> >  > renato.fab...@gmail.com> wrote:
> >
> >>Ok, I looked through the LilyPond code.
> >>
> >>Notes:
> >>*) There seems to be some emphasis on the perspective given in the book
> >>Die Jazzmethode fuer Klavier 1 (Klaus Ignatzek).
> >>Can someone send me a PDF of this book or know how can I find
> >>an online copy at least of the most important parts for this case?
> >
> > I do not have a PDF or a reference.  But I think that the emphasis on
> > Ignatzek need not be exclusive. That is, Ignatzek has a point of view on
> > chords.  So do Brandt and Roemer.  Lilypond should be able to support
> > anybody's view, not just one person's.
> >
> >>
> >>*) Just so I (and other proponents) get it very clear, what do we need
> >>beyond our current capability exposed in the snippet:
> >>http://git.savannah.gnu.org/cgit/lilypond.git/tree/
> >>Documentation/snippets/chord-name-exceptions.ly
> >
> > This capability reflects the current state of LilyPond's chord naming
> > structure, which is to try to guess the name of the chord by analyzing
> > pitches.  So if you want to define a new chord name, you do it by
> > defining the list of pitches in the chord.  It's doable, but the chord
> > itself doesn't carry any semantic information.
>
> Except when it does.  Music properties "inversion", "octavation", "bass"
> carry semantic information beyond the chord pitch.
>
> > The proposal is to put the necessary information describing the
> > semantics of the chord in the chord itself, rather than trying to
> > recreate it from the notes present in the chord.
>
> I am not saying that the current semantic information attached to chords
> by the \chordmode parser is suitable for all purposes and/or
> defined/utilized/documented to the best possible degree.
>
> But ignoring it would make for an awkward start.
>
> > Here's an old proposal that never made it to application:
> > https://lists.gnu.org/archive/html/lilypond-user/2009-01/msg00897.html
> >
> > Here's an interesting discussion on chord names that addresses a
> suspended
> > chord:
> > https://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00864.html
> >
> > Here's another thread that shows problems with chord naming:
> > https://lists.gnu.org/archive/html/lilypond-user/2008-02/msg00391.html
> >
> > Here's an email discussing another possible benefit of the approach:
> > https://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00155.html
> >
> > And another discussion of some of the challenges:
> > https://lists.gnu.org/archive/html/lilypond-devel/2002-05/msg00069.html
> >
> > Here's one that actually started the thinking for the GSOC project:
> > https://lists.gnu.org/archive/html/lilypond-user/2014-12/msg00617.html
> >
> > Somehow the last thread got broken; here's the follow up:
> > https://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00065.html
> >
> > I hope this is helpful.
>
> Certainly something to look through.
>
> --
> David Kastrup
>



-- 
Renato Fabbri
GNU/Linux User #479299
labmacambira.sourceforge.net
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[David Kastrup]

Carl Sorensen  writes:

> On 4/2/17 1:13 AM, "lilypond-devel on behalf of Renato Fabbri"
>  renato.fab...@gmail.com> wrote:
>
>>Ok, I looked through the LilyPond code.
>>
>>Notes:
>>*) There seems to be some emphasis on the perspective given in the book
>>Die Jazzmethode fuer Klavier 1 (Klaus Ignatzek).
>>Can someone send me a PDF of this book or know how can I find
>>an online copy at least of the most important parts for this case?
>
> I do not have a PDF or a reference.  But I think that the emphasis on
> Ignatzek need not be exclusive. That is, Ignatzek has a point of view on
> chords.  So do Brandt and Roemer.  Lilypond should be able to support
> anybody's view, not just one person's.
>
>>
>>*) Just so I (and other proponents) get it very clear, what do we need
>>beyond our current capability exposed in the snippet:
>>http://git.savannah.gnu.org/cgit/lilypond.git/tree/
>>Documentation/snippets/chord-name-exceptions.ly
>
> This capability reflects the current state of LilyPond's chord naming
> structure, which is to try to guess the name of the chord by analyzing
> pitches.  So if you want to define a new chord name, you do it by
> defining the list of pitches in the chord.  It's doable, but the chord
> itself doesn't carry any semantic information.

Except when it does.  Music properties "inversion", "octavation", "bass"
carry semantic information beyond the chord pitch.

> The proposal is to put the necessary information describing the
> semantics of the chord in the chord itself, rather than trying to
> recreate it from the notes present in the chord.

I am not saying that the current semantic information attached to chords
by the \chordmode parser is suitable for all purposes and/or
defined/utilized/documented to the best possible degree.

But ignoring it would make for an awkward start.

> Here's an old proposal that never made it to application:
> https://lists.gnu.org/archive/html/lilypond-user/2009-01/msg00897.html
>
> Here's an interesting discussion on chord names that addresses a suspended
> chord: 
> https://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00864.html
>
> Here's another thread that shows problems with chord naming:
> https://lists.gnu.org/archive/html/lilypond-user/2008-02/msg00391.html
>
> Here's an email discussing another possible benefit of the approach:
> https://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00155.html
>
> And another discussion of some of the challenges:
> https://lists.gnu.org/archive/html/lilypond-devel/2002-05/msg00069.html
>
> Here's one that actually started the thinking for the GSOC project:
> https://lists.gnu.org/archive/html/lilypond-user/2014-12/msg00617.html
>
> Somehow the last thread got broken; here's the follow up:
> https://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00065.html
>
> I hope this is helpful.

Certainly something to look through.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[Carl Sorensen]

On 4/2/17 1:13 AM, "lilypond-devel on behalf of Renato Fabbri"
 wrote:

>Ok, I looked through the LilyPond code.
>
>Notes:
>*) There seems to be some emphasis on the perspective given in the book
>Die Jazzmethode fuer Klavier 1 (Klaus Ignatzek).
>Can someone send me a PDF of this book or know how can I find
>an online copy at least of the most important parts for this case?

I do not have a PDF or a reference.  But I think that the emphasis on
Ignatzek need not be exclusive. That is, Ignatzek has a point of view on
chords.  So do Brandt and Roemer.  Lilypond should be able to support
anybody's view, not just one person's.

>
>*) Just so I (and other proponents) get it very clear, what do we need
>beyond our current capability exposed in the snippet:
>http://git.savannah.gnu.org/cgit/lilypond.git/tree/
>Documentation/snippets/chord-name-exceptions.ly

This capability reflects the current state of LilyPond's chord naming
structure, which is to try to guess the name of the chord by analyzing
pitches.  So if you want to define a new chord name, you do it by defining
the list of pitches in the chord.  It's doable, but the chord itself
doesn't carry any semantic information.

The proposal is to put the necessary information describing the semantics
of the chord in the chord itself, rather than trying to recreate it from
the notes present in the chord.


Here's an old proposal that never made it to application:
https://lists.gnu.org/archive/html/lilypond-user/2009-01/msg00897.html

Here's an interesting discussion on chord names that addresses a suspended
chord: 
https://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00864.html

Here's another thread that shows problems with chord naming:
https://lists.gnu.org/archive/html/lilypond-user/2008-02/msg00391.html

Here's an email discussing another possible benefit of the approach:
https://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00155.html

And another discussion of some of the challenges:
https://lists.gnu.org/archive/html/lilypond-devel/2002-05/msg00069.html

Here's one that actually started the thinking for the GSOC project:
https://lists.gnu.org/archive/html/lilypond-user/2014-12/msg00617.html

Somehow the last thread got broken; here's the follow up:
https://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00065.html

I hope this is helpful.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[Renato Fabbri]

Ok, I looked through the LilyPond code.

Notes:
*) There seems to be some emphasis on the perspective given in the book
Die Jazzmethode fuer Klavier 1 (Klaus Ignatzek).
Can someone send me a PDF of this book or know how can I find
an online copy at least of the most important parts for this case?

*) Just so I (and other proponents) get it very clear, what do we need
beyond our current capability exposed in the snippet:
http://git.savannah.gnu.org/cgit/lilypond.git/tree/
Documentation/snippets/chord-name-exceptions.ly

*) For the other students interested in this project,
I got a better idea of how LilyPond works by going through
scm/*chord*
ly/*chord*
Documents/snippets/*chord*
and playing MIDI files with FluidSynth (with the Timbres Of Heaven
SoundFont ;-)
while looking the rendered PDF..
It was a real treat.

PS. sorry for taking a long time to reply.
I though I have sent this message, I found it in the drafts while waiting
for replies.

Best regards!

On Sat, Apr 1, 2017 at 7:26 AM, David Kastrup  wrote:

> Renato Fabbri  writes:
>
> > On Fri, Mar 31, 2017 at 12:45 PM, David Kastrup  wrote:
> >
> >> You'll find that the same notes can already be distinguished as either
> >> chord/inversion.
> >>
> >> One question certainly is whether the information we use for that is a
> >> good fit and whether it should be easier to create this kind of
> >> information outside of \chordmode .
> >>
> >
> > How would one create this information outside \chordmode?
>
> Using \withMusicProperty .  Namely, there currently is no dedicated user
> interface outside of \chordmode for setting those properties.  One
> reason that it might make sense to have one is for making results of the
> fretboard exception list more applicable to chord recognition and other
> manipulations so that they can be used outside of fretboard contexts as
> well.
>
> --
> David Kastrup
>



-- 
Renato Fabbri
GNU/Linux User #479299
labmacambira.sourceforge.net
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[David Kastrup]

Renato Fabbri  writes:

> On Fri, Mar 31, 2017 at 12:45 PM, David Kastrup  wrote:
>
>> You'll find that the same notes can already be distinguished as either
>> chord/inversion.
>>
>> One question certainly is whether the information we use for that is a
>> good fit and whether it should be easier to create this kind of
>> information outside of \chordmode .
>>
>
> How would one create this information outside \chordmode?

Using \withMusicProperty .  Namely, there currently is no dedicated user
interface outside of \chordmode for setting those properties.  One
reason that it might make sense to have one is for making results of the
fretboard exception list more applicable to chord recognition and other
manipulations so that they can be used outside of fretboard contexts as
well.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[Renato Fabbri]

On Fri, Mar 31, 2017 at 12:45 PM, David Kastrup  wrote:

> lilyp...@schoepfer.info writes:
>
>  I hope to send something more specifically about chords after some
> rest.
> >>>
> >>> Here are my 2cents:
> >>> Defining the chords by a list of notes for jazz tunes can't  ever
> >>> cover all sorts of voicings.
> >>
> >> Are you confusing "pitch" and "note" here?  Notes are a LilyPond data
> >> structure that have more properties than just a pitch.  Several are
> >> already used for disambiguating chords entered in chord mode.
> >
> > Very likely, i don't know much of the lilypond internals.
> >
> >>> Fortunately, this isn't at all needed for typesetting e.g. a
> >>> jazz-tune.  It is sufficient to only have the root note, e.g. C from
> >>> C:m7, in a musical/transposeable context, the rest of the chord(here
> >>> m7) could just be represented as text as-it-is.
> >>>
> >>> Maybe, from this point of view, there could be an alternative method
> >>> for typestting chords be implemented?
> >>
> >> I don't see what you are trying to achieve here.
> >
> > English is not my native language, but i try:
> > I wanted to point out, that the idea to get e.g.
> > c' e' g' a' from the chord c:6 is not really correct/complete and not
> > of much use, for various reasons:
> > -unclear in which octave
> > -unclear which voicing
> > -Not all pitches needed to be there(may be too much/dense) to make the
> > chord clear
> > -c' e' g' a' could be interpreded as chord a:m7
>
> Please take a look at
>
>
>
> You'll find that the same notes can already be distinguished as either
> chord/inversion.
>
> One question certainly is whether the information we use for that is a
> good fit and whether it should be easier to create this kind of
> information outside of \chordmode .
>

How would one create this information outside \chordmode?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[David Kastrup]

lilyp...@schoepfer.info writes:

 I hope to send something more specifically about chords after some rest.
>>>
>>> Here are my 2cents:
>>> Defining the chords by a list of notes for jazz tunes can't  ever
>>> cover all sorts of voicings.
>>
>> Are you confusing "pitch" and "note" here?  Notes are a LilyPond data
>> structure that have more properties than just a pitch.  Several are
>> already used for disambiguating chords entered in chord mode.
>
> Very likely, i don't know much of the lilypond internals.
>
>>> Fortunately, this isn't at all needed for typesetting e.g. a
>>> jazz-tune.  It is sufficient to only have the root note, e.g. C from
>>> C:m7, in a musical/transposeable context, the rest of the chord(here
>>> m7) could just be represented as text as-it-is.
>>>
>>> Maybe, from this point of view, there could be an alternative method
>>> for typestting chords be implemented?
>>
>> I don't see what you are trying to achieve here.
>
> English is not my native language, but i try:
> I wanted to point out, that the idea to get e.g.
> c' e' g' a' from the chord c:6 is not really correct/complete and not
> of much use, for various reasons:
> -unclear in which octave
> -unclear which voicing
> -Not all pitches needed to be there(may be too much/dense) to make the
> chord clear
> -c' e' g' a' could be interpreded as chord a:m7

Please take a look at

mus = \chordmode { c2:6 a:m7/c }

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

\void \displayMusic \mus

You'll find that the same notes can already be distinguished as either
chord/inversion.

One question certainly is whether the information we use for that is a
good fit and whether it should be easier to create this kind of
information outside of \chordmode .

But it's not like there is nothing there yet.

> In a reallife jazz context, it's up to the player/band what to do with
> chords. Lilypond is not a playalong-generator, but lilypond should
> typeset chords. Lilypond can do this in most cases, but in my opinion
> the mapping to single pitches/notenames is an unneeded, complicated
> and errorprone overhead.

If you want to output Midi, you need pitches anyway.

> So, reducing the lilypond chord-handling to a singel pitch/root-note +
> text/chord-description would be sufficient to typeset.
> This way, all sorts of chord-types. e.g. c7/b9/#9/b5/whatever are
> possible, without worrying about implementing all possibilities how a
> chord could be interpreted.

Text does not transpose very well.  Various instruments (guitar, banjo,
accordion) have various ways of picking voicings that don't correspond
with the "canonical" description but still have some representation in
tablature/score.

One current problem with chord naming and entry is that, for example,
guitar voicings are hardwired into FretBoard contexts and you can't
actually get them out of there (for example, for putting them in
tablature).  It's also hard to create descriptive chord names when you
start with a score.

There are a number of problems where the current implementation and its
representation makes things harder to bounce around.

-- 
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[lilypond]

I hope to send something more specifically about chords after some rest.


Here are my 2cents:
Defining the chords by a list of notes for jazz tunes can't  ever
cover all sorts of voicings.


Are you confusing "pitch" and "note" here?  Notes are a LilyPond data
structure that have more properties than just a pitch.  Several are
already used for disambiguating chords entered in chord mode.


Very likely, i don't know much of the lilypond internals.


Fortunately, this isn't at all needed for typesetting e.g. a
jazz-tune.  It is sufficient to only have the root note, e.g. C from
C:m7, in a musical/transposeable context, the rest of the chord(here
m7) could just be represented as text as-it-is.

Maybe, from this point of view, there could be an alternative method
for typestting chords be implemented?


I don't see what you are trying to achieve here.


English is not my native language, but i try:
I wanted to point out, that the idea to get e.g.
c' e' g' a' from the chord c:6 is not really correct/complete and not of 
much use, for various reasons:

-unclear in which octave
-unclear which voicing
-Not all pitches needed to be there(may be too much/dense) to make the 
chord clear

-c' e' g' a' could be interpreded as chord a:m7
...

In a reallife jazz context, it's up to the player/band what to do with 
chords. Lilypond is not a playalong-generator, but lilypond should 
typeset chords. Lilypond can do this in most cases, but in my opinion
the mapping to single pitches/notenames is an unneeded, complicated and 
errorprone overhead.


So, reducing the lilypond chord-handling to a singel pitch/root-note + 
text/chord-description would be sufficient to typeset.
This way, all sorts of chord-types. e.g. c7/b9/#9/b5/whatever are 
possible, without worrying about implementing all possibilities how a 
chord could be interpreted.


I hope something is more clear now ;-)

Johannes




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[David Kastrup]

lilyp...@schoepfer.info writes:

>> I hope to send something more specifically about chords after some rest.
>
> Here are my 2cents:
> Defining the chords by a list of notes for jazz tunes can't  ever
> cover all sorts of voicings.

Are you confusing "pitch" and "note" here?  Notes are a LilyPond data
structure that have more properties than just a pitch.  Several are
already used for disambiguating chords entered in chord mode.

> Fortunately, this isn't at all needed for typesetting e.g. a
> jazz-tune.  It is sufficient to only have the root note, e.g. C from
> C:m7, in a musical/transposeable context, the rest of the chord(here
> m7) could just be represented as text as-it-is.
>
> Maybe, from this point of view, there could be an alternative method
> for typestting chords be implemented?

I don't see what you are trying to achieve here.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[lilypond]

I hope to send something more specifically about chords after some rest.


Here are my 2cents:
Defining the chords by a list of notes for jazz tunes can't  ever cover 
all sorts of voicings. Fortunately, this isn't at all needed for 
typesetting e.g. a jazz-tune.
It is sufficient to only have the root note,  e.g. C from C:m7, in a 
musical/transposeable context, the rest of the chord(here m7) could just 
be represented as text as-it-is.


Maybe, from this point of view, there could be an alternative method for 
typestting chords be implemented?


Johannes

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[Renato Fabbri]

Thanks for the replies.
Today I compiled LilyPond using the repository code.
I also went through the Contributor’s Guide, which was very instructive.
I hope to send something more specifically about chords after some rest.
Best,
Renato


On Wed, Mar 29, 2017 at 8:07 PM, Carl Sorensen  wrote:

>
>
> On 3/29/17 2:13 PM, "David Kastrup"  wrote:
>
> >Carl Sorensen  writes:
> >
> >> On 3/29/17 8:57 AM, "lilypond-devel on behalf of Renato Fabbri"
> >>  >> renato.fab...@gmail.com> wrote:
> >>
> >>>Thanks for the feedback.
> >>>Yes, I should be an enrolled student by May 4.
> >>>
> >>>Could you give me examples of what you consider an internal chord
> >>>structure
> >>>(semitone counting?)?
> >> The internal chord structure is a Guile (scheme) list containing
> >>pitches,
> >> a duration, and events.
> >
> >I beg to differ.  The tangible representation we are working with is a
> >list of note events.  When this list of note events is the result of
> >chord entry, some additional information is put in to make identifying
> >root/inversion possible.
>
> I agree that your statement is more precise.  In my mind, this project is
> about deciding what additional information is necessary to give us all the
> semantics we would like to have to be able to properly deduce the
> appropriate chord name, and how this additional information should be
> stored.
>
> >Other forms may be used for the internals of various chord
> >naming/identifying routines, but they are an implementation detail.  The
> >note events are the information bottleneck that every chord is passing
> >through: if the information in there is not sufficient, it has to be
> >amended and one has to see how to get the information best into there
> >and out again.
>
> If the information in the list of note events is not sufficient, we now
> need to guess the semantics.  This GSOC project won't change that; we
> aren't proposing to improve our ability to guess the semantics.
>
> We eventually want to get to the point where when we parse something like
> e:m7.5-, we don't just get the pitches, but we get the appropriate
> semantic information to properly identify this chord in a rational chord
> naming system.  So we'd want to capture the root, the quality, the
> inversion, and whatever else needs to be captured.  Once we have that, we
> can separate the pitch identification from the naming process.  It should
> help separate things.
>
> Thanks,
>
> Carl
>
>


-- 
GNU/Linux User #479299
labmacambira.sourceforge.net
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[Carl Sorensen]

On 3/29/17 2:13 PM, "David Kastrup"  wrote:

>Carl Sorensen  writes:
>
>> On 3/29/17 8:57 AM, "lilypond-devel on behalf of Renato Fabbri"
>> > renato.fab...@gmail.com> wrote:
>>
>>>Thanks for the feedback.
>>>Yes, I should be an enrolled student by May 4.
>>>
>>>Could you give me examples of what you consider an internal chord
>>>structure
>>>(semitone counting?)?
>> The internal chord structure is a Guile (scheme) list containing
>>pitches,
>> a duration, and events.
>
>I beg to differ.  The tangible representation we are working with is a
>list of note events.  When this list of note events is the result of
>chord entry, some additional information is put in to make identifying
>root/inversion possible.

I agree that your statement is more precise.  In my mind, this project is
about deciding what additional information is necessary to give us all the
semantics we would like to have to be able to properly deduce the
appropriate chord name, and how this additional information should be
stored.

>Other forms may be used for the internals of various chord
>naming/identifying routines, but they are an implementation detail.  The
>note events are the information bottleneck that every chord is passing
>through: if the information in there is not sufficient, it has to be
>amended and one has to see how to get the information best into there
>and out again.

If the information in the list of note events is not sufficient, we now
need to guess the semantics.  This GSOC project won't change that; we
aren't proposing to improve our ability to guess the semantics.

We eventually want to get to the point where when we parse something like
e:m7.5-, we don't just get the pitches, but we get the appropriate
semantic information to properly identify this chord in a rational chord
naming system.  So we'd want to capture the root, the quality, the
inversion, and whatever else needs to be captured.  Once we have that, we
can separate the pitch identification from the naming process.  It should
help separate things.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[David Kastrup]

Carl Sorensen  writes:

> On 3/29/17 8:57 AM, "lilypond-devel on behalf of Renato Fabbri"
>  renato.fab...@gmail.com> wrote:
>
>>Thanks for the feedback.
>>Yes, I should be an enrolled student by May 4.
>>
>>Could you give me examples of what you consider an internal chord
>>structure
>>(semitone counting?)?
> The internal chord structure is a Guile (scheme) list containing pitches,
> a duration, and events.

I beg to differ.  The tangible representation we are working with is a
list of note events.  When this list of note events is the result of
chord entry, some additional information is put in to make identifying
root/inversion possible.

Other forms may be used for the internals of various chord
naming/identifying routines, but they are an implementation detail.  The
note events are the information bottleneck that every chord is passing
through: if the information in there is not sufficient, it has to be
amended and one has to see how to get the information best into there
and out again.

>>And an internal representation (c2:min7 ?)?
> c2:min7 is an input syntax.
>
>>I am assuming that the output formating
>>is e.g. Cm7.
>
> Yes, that is correct.

Yup.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[Carl Sorensen]

On 3/29/17 8:57 AM, "lilypond-devel on behalf of Renato Fabbri"
 wrote:

>Thanks for the feedback.
>Yes, I should be an enrolled student by May 4.
>
>Could you give me examples of what you consider an internal chord
>structure
>(semitone counting?)?
The internal chord structure is a Guile (scheme) list containing pitches,
a duration, and events.

>And an internal representation (c2:min7 ?)?
c2:min7 is an input syntax.

>I am assuming that the output formating
>is e.g. Cm7.

Yes, that is correct.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[Renato Fabbri]

Thanks for the feedback.
Yes, I should be an enrolled student by May 4.

Could you give me examples of what you consider an internal chord structure
(semitone counting?)?
And an internal representation (c2:min7 ?)?
I am assuming that the output formating
is e.g. Cm7.
PS. I am referring explicitly to the text of the GSoC project idea.

Em 29 de mar de 2017 09:11, "Urs Liska"  escreveu:

Hi Renato,


Am 29.03.2017 um 13:54 schrieb Carl Sorensen:
> Congratulations on your dissertation completion.  That's a big step!  If
> you're interested in the project, we'd be delighted to have you apply.

just to add to this:
You are *not* too late until you miss the GSoC deadline. Of course, the
later you start, the less chance you have to discuss and improve your
suggestion, so you should go straight ahead now.

Just one question: I assume you will still be an enrolled student by May 4?

Urs

--
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[Urs Liska]

Hi Renato,


Am 29.03.2017 um 13:54 schrieb Carl Sorensen:
> Congratulations on your dissertation completion.  That's a big step!  If
> you're interested in the project, we'd be delighted to have you apply.

just to add to this:
You are *not* too late until you miss the GSoC deadline. Of course, the
later you start, the less chance you have to discuss and improve your
suggestion, so you should go straight ahead now.

Just one question: I assume you will still be an enrolled student by May 4?

Urs

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

[Carl Sorensen]

Dear Renato,

>
>have you already made some systematization of the chords?
>There is a list here:
>https://en.wikipedia.org/wiki/List_of_chords
>and I got myself interested in
>analyzing the context in which the chord is incident to have the
>"ability to capture the essence of complex chords",
>as stated in the GSoC ideas page.

The list of chords is interesting.  I can't speak for all of the
users/developers, but personally I don't think I would be interested in
using the names of the chords that are on the left hand side of that
table.  I'm less interested in having a unique name for each chord, and
more interested in having a structure that supports chord characteristics
(such as the quality which is listed in the table).

>I also have some interests in symmetry which
>might help with representing symmetric scale chords
>such as derived from Messiaen's modes of limited transposition.
>Might chords not from the 12 tones system
>or in other temperaments be of interest?

I suppose that there could be some interest in chords that are not in
standard temperaments, but I don't think that is the focus of interest for
this project.  I don't believe we are trying to expand the range of chords
that LilyPond can capture with this project as much as we are trying to
improve the semantics of what we already have.

That being said, I don't believe there would be any problem with adding
non-standard chords in addition to improving the semantics.

>
>I understand it might be late for coping with GSoC, but if you find it
>suitable,
>I might apply.
>My apologies for not making this contact earlier, but I handed my
>doctorate
>dissertation a few days ago and could not concentrate as needed until now.
>Some info about my research and software development efforts are gathered
>here:
>https://pastebin.com/iNNuN4fy
>Anyway, this topic might be of use for the LilyPond community as a whole
>and for
>developments outside GSoC.

Congratulations on your dissertation completion.  That's a big step!  If
you're interested in the project, we'd be delighted to have you apply.

Thanks,

Carl Sorensen



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel