Re: Improve internal chord structure
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
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
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
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
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
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
Improve internal chord structure
Dear developers, 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. 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 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. Best Regards, 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
