> The problem with a lookup table is that is assumes a short finite list of
chord we need to support, but that's not the case.
I'm assuming that you're trying to emulate what an accompanist would do,
which typically involves reducing complex chords down to their essential
elements.
In practice, there tends to be a tractable number of chords to support. See
the last pages of the Improv-Visor documentation, for example:
https://www.cs.hmc.edu/~keller/jazz/improvisor/LeadsheetNotation.pdf
Not necessarily *short*, but finite. It's not like people are commonly
discovering new chords on a regular basis. ;-)
Lookup tables can capture common practice without having to try to encode a
bunch of rules and exceptions. If it's not in the table, you can fall back
to an algorithm.
-- David
On Tue, Mar 15, 2016 at 5:57 PM, Marc Sabatella <m...@outsideshore.com>
wrote:
> The problem with a lookup table is that is assumes a short finite list of
> chord we need to support, but that's not the case. There are abitrarily
> many chords to support - eg, Dbma9#5sus. But sure, the parsing already
> reduces everything to a basic quality (major, minor, etc) and extension, so
> a lookup table for that much is not totally unreasonable. Not sure it buys
> you anything over doing it algorithmically, thiugh.
>
> On Tue, Mar 15, 2016 at 6:14 PM David Cuny <davidfc...@gmail.com> wrote:
>
>> > I am speculating/thinking aloud and at this point I am beginning to
>> > believe it is overengineering,
>>
>> Yes - you can get away with a *lot* with keyboard accompaniment. People
>> generally aren't going to complain if voices drop out, skip, or even leap
>> every now and then.
>>
>> As you suggested, use a simple lookup table to get the chordal notes
>> (using half-steps from the root) such as this:
>>
>> maj: [0, 4, 7]
>> min: [0, 3, 7]
>> sus4: [0, 5, 7]
>> min7: [0, 3, 7, 10]
>> 7: [0, 4, 7, 10]
>> maj7: [0, 4, 7, 11]
>> 9: [4, 7, 10, 2]
>> 11: [7, 10, 2, 5]
>>
>> Add the MIDI note of the root, and you get the MIDI note numbers of the
>> chordals.
>>
>> To "voice" the chord, just choose an upper bound for the chord (MIDI 76
>> works for me), and then shift the notes into place:
>>
>> // force each note to lie an octave below the maximum
>> for each note in notes
>> while note < highest_note-12
>> note += 12;
>>
>> That's all you need to get surprisingly good results.
>>
>> -- David
>>
>>
>> On Tue, Mar 15, 2016 at 3:55 PM, Tobia Tesan <tobia.te...@gmail.com>
>> wrote:
>>
>>> On 15/03/2016 23:29, Marc Sabatella wrote:
>>>
>>> > Indeed, voice leading is good to optimize, but we also need good
>>> > voicings for the initial chord of a section, where there is no
>>> > previoia chord to base on.
>>>
>>> I am speculating/thinking aloud and at this point I am beginning to
>>> believe it is overengineering, but to get a globally optimum selection
>>> of voicings, including the first chord, I don't think it would be
>>> *terribly* difficult to cast the problem like this:
>>>
>>> * have a lookup table with a standard library of voicings, 4 or 5 per
>>> chord, in a fixed range (thus avoiding the "drfting problem")
>>> * have a matrix of penalties for each pair of adjacent voicings, defined
>>> to be as the sum of the broken rules, with weights (e.g. +1 for a step,
>>> +5 for a leap, +100 for something Very Bad, etc, as outlined in David's
>>> message)
>>> * chose an optimal combination of chords to minimize the sum of penalties
>>>
>>> I think a modern machine can be made to solve it reasonably fast for a
>>> sequence of ~100 chords.
>>>
>>> > Also, except for jazz, I think most people would probably expect the
>>> > same chord symbol to always produce the same voicing, which is
>>> > something else to consider.
>>>
>>> Are you thinking "pop music"?
>>> Because that crowd can probably be satisfied with a standard library of
>>> open chords, wouldn't they?
>>>
>>> Good night :)
>>>
>>> --
>>> Tobia Tesan
>>> <tobia.te...@gmail.com>
>>> <sip:tobia.te...@ekiga.net>
>>> "If you don't fail at least 90 percent of the time, you're not aiming
>>> high enough."
>>> -- Alan Kay
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Transform Data into Opportunity.
>>> Accelerate data analysis in your applications with
>>> Intel Data Analytics Acceleration Library.
>>> Click to learn more.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>>> _______________________________________________
>>> Mscore-developer mailing list
>>> Mscore-developer@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mscore-developer
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>> _______________________________________________
>> Mscore-developer mailing list
>> Mscore-developer@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mscore-developer
>>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Mscore-developer mailing list
> Mscore-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mscore-developer
>
>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
