Hello, and: Chord Playback GSoC idea
Locked
12
12
Hello, and: Chord Playback GSoC idea
 
|
Hi all.
I'm Tobia; some of you know me by the handle of t0by on Freenode. I'm a MSc student at the University of Padua and a slightly music-obsessed person; you can find a more thorough bio below. I am considering participating in GSoC with MuseScore this year and possibly becoming a regular contributor. I have previously participated in GSoC in 2013 with ScummVM, and kept contributing on my (little) spare time. I have my eyes set on the chord playback idea, which is a feature I've always wanted myself in a notation program. After some chatting with Marc and Nicolas and some thinking I've drafted a very very early proposal; very rough, it's little more than an idea. Still, I would be thrilled to know your thoughts about it. You can find an outline of it below. There is some ASCII art sprinkled, I apologize to those who have a variable width font as their default setting. Thank you very much; have a nice day! Tobia ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Title: Chord playback ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Name: Tobia Tesan Email: [hidden email] IRC: t0by on Freenode GitHub: github.com/tobiatesan (I think there is some terrible Qt code I wrote in my freshman year for a project in here; I apologize for that) Synopsis: ========= This proposal is for building and adding a easily maintainable, extensible system for playing back chord symbols in Musescore. It would include an easily extensible infrastructure and features to realize chord symbols in their harmonic and rhythmical dimension. It would also include an initial standard 4-part-harmony and a strummer-guitar-chords implementation. Benefits to MuseScore: ====================== These features answer the need of composers to quickly jot down fake book-style sheets and preview them. The two initial implementation themselves answer two very large use cases - very broadly speaking, pop/rock and non-pop/rock western music. A semi-credible guitar strumming (listed below as a stretch deliverable) is a particularly valuable tool to professional songwriters who can quickly jot down a song on a train and preview them to a client immediately (perhaps adding bass and drum kit staff); I believe that this can make MuseScore stand out. Deliverables: ============= MIDTERM: - Prototype offline chord harmonizer in Qt/C++ (exact rules TBD) - Prototype offline rhythm realizer in Qt/C++ - Tests FINAL: - Adapter, UI tweaks and integration - Guitar chord harmonizer implementation STRETCH DELIVERABLES: - Guitar strummer - RenderMidi partial refactor - "Render to staff" / "Freeze" harmony Project Details: ================ The architecture I have thought of is an offline two-step pipeline; in the first step chord symbols are harmonized/voiced according to a given algorithm or ruleset (e.g. "4-part harmony" or "always and only first-position acoustic guitar chords"); in the second step the resulting harmony is rhythmically realized. Finally the result is rendered to MIDI +------------+ chords -->| | [A C G] | HARMONIZER | | | meta---> +------------+ ------___--- | harmony ------___--- v ---______--- +------------+ ___ | | --- ___--- slash --->| RHYTHM | notation | PLAYER | [^v^v ] | | tempo --->+------------+ | | harmony + rhythm | | v -- - -- - __ _ -- - MIDI +-------------+ -- - -- - __ _ -- - sync | | -- - __ _ __ _ -- - ----> | RENDERER | __ _ | | -- - __ _ -- - +-------------+ | v MIDI [0x80 0xB1 0xFF 0x80 0xB2 0x... ] Initially, infrastructure and a few simple implementations would be provided, with the idea of allowing future extension: +----------+ | HARMONZR | +----------+ ^ /_\ | +-------------+ | | +----------+ +-----------+ | 4-PART | | ACS GUIT | +----------+ +-----------+ +----------+ | RHTHMPLR | +----------+ ^ /_\ | +-------------+ | | +----------+ +-----------+ | GATE | | GT STRUM | +----------+ +-----------+ Ideally, the first two pairs of implementation provided would be 1. 4-part harmony and a simple gater 2. guitar chords realization and a strummer By "strummer" I mean something that can render the characteristic effect of guitar strumming, rendering a chord as a very fast arpeggio, ascending or descending depending on picking direction. 2. would be an optional deliverable, in case no particular difficulties are encountered. Initially, these would be prototyped "in a vacuum", in Qt/C++, and later on plugged into the rendering engine (i.e. render_midi.cpp) with a thin adapter layer. This might include a bit of refactoring work on RenderMidi, to be defined. Project Schedule: ================= Schedule TBD, based on the mid-term and final deliverables above if confirmed. Bio: ==== I'm Tobia, I'm a MSc student at the University of Padua, where I earned my BSc with a 108/110 final grade. My interests are chiefly Machine Learning, Data Mining, Artifical Intelligence, Computer Graphics and Software Engineering in general. I have previously encountered Qt 1. academically and 2. while doing design and prototyping work on a Qt application for "a leading company in the field of Trusted Certification Solutions and Electronic Document Management services". I previously participated in GSoC in 2013 with ScummVM and kept contributing since. I have also been mildly obsessed with music from an early age. My current favourites are Chopin and Janacek's piano music, Poulenc's chamber music, Dowland's lute music and early music in general; Cannonball Adderley, Mingus, Kate Bush. I have not received much formal musical education, but I can read music, I play piano and sometimes I make noises with guitars. I am somewhat proficient with sequencers; I have used for an especially long time Ableton Live. Once I built my own MIDI-controlled analog synthesizer around a 16F84 IC and a UART; didn't sound very good. I played in a few prog rock and metal bands. Didn't sound very good either. Another time I wrote music to an amateur theatre production, with somewhat better results. -- Tobia Tesan <[hidden email]> <sip:[hidden email]> "The question of whether Machines Can Think is about as relevant as the question of whether Submarines Can Swim." -- Edsger Dijkstra ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
On 14/03/2016 19:36, Tobia Tesan wrote:
> It would also include an initial standard 4-part-harmony and a > strummer-guitar-chords implementation. On a second thought, "4-part-harmony" is probably the wrong word here, since we don't output to separate voices (and thus a number of constraints such as "voices mustn't cross" fall). I think a lot of parallel motion or doubling seventh is still generally best avoided, as are lots of leaps. I think, if the idea is to interest, that the exact rules to be implemented can be discussed with the mentor - possibly a subset that's "good enough sounding" in most circumstances but doesn't require a PhD thesis worth of work. > (e.g. "4-part harmony" or "always and only first-position acoustic > guitar chords"); Similarly, while on the subject, I believe the correct english is "open chords". -- Tobia Tesan <[hidden email]> <sip:[hidden email]> ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
There are a number of existing systems (Band in a Box, Chord Pulse, Impro-Visor) which sound similar to what you're suggesting. Since they've already solved the problem, you might want to consider looking at them to see what's been successful. One of the key features of these programs is ability to select a particular style of accompaniment.Here's a link to the Impro-Visor style editor documentation: https://www.cs.hmc.edu/~keller/jazz/improvisor/StyleEditorTutorial.pdf Most of these styles are predominantly rhythmic, so voice leading really isn't an issue. Keeping chords to 4 essential tones and constraining them to lie within a given range (as Impro-Visor does) should be sufficient. I think it might make more sense to write the accompaniment directly to staffs, rather than output it as MIDI. If you had "special" staffs (with standard names, such as "accompaniment bass"), the problem becomes one of converting the style into notation, and the end result is better integrated into MuseScore. -- David On Mon, Mar 14, 2016 at 12:51 PM, Tobia Tesan <[hidden email]> wrote: On 14/03/2016 19:36, Tobia Tesan wrote: ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
On 14/03/2016 23:35, David Cuny wrote: > There are a number of existing systems (/Band in a Box/, /Chord > Pulse/, /Impro-Visor/) which sound similar to what you're suggesting. > Since they've already solved the problem, you might want to consider > looking at them to see what's been successful. > > One of the key features of these programs is ability to select a > particular style of accompaniment. > > Here's a link to the Impro-Visor style editor documentation: > https://www.cs.hmc.edu/~keller/jazz/improvisor/StyleEditorTutorial.pdf > <https://www.cs.hmc.edu/%7Ekeller/jazz/improvisor/StyleEditorTutorial.pdf> > > Most of these styles are predominantly rhythmic, so voice leading > really isn't an issue. Keeping chords to 4 essential tones and > constraining them to lie within a given range (as /Impro-Visor/ does) > should be sufficient. > > I think it might make more sense to write the accompaniment directly > to staffs, rather than output it as MIDI. If you had "special" staffs > (with standard names, such as "accompaniment bass"), the problem > becomes one of converting the style into notation, and the end result > is better integrated into MuseScore. Hi David, thanks for the really useful pointers. I don't think that the use cases for Band In A Box and similar "arranger" software and the "chord playback" idea from https://musescore.org/en/developers-handbook/google-summer-code/ideas-2016 are *exactly* the same, though. Notably, I think that the former doesn't afford the luxury of making offline decisions. Re: your second point, from discussion on the channel with Marc and others I also *seem* to understand that that 1. we really don't want an arranger built into MuseScore and 2. direct playback should be supported, even if along with a "write to staff" feature. I also seem to understand that the possibility of several style-specific rulesets for voicing should be at least considered (but I might have completely misunderstood Marc's point - please jump in :-). In this respect, a set of 4-note voicing rules appears, in my uninformed opinion, interesting both for its practical results and as a relatively straightforward "proof of concept"; there seems to be some literature about modeling that kind of problem (notably, as a CSP: https://www.csl.sony.fr/downloads/papers/2000/pachet-constraints2000.pdf for the TL;DR, https://wikis.utexas.edu/download/attachments/3736529/musiccomp-harmonysearch.pdf and http://quod.lib.umich.edu/cgi/p/pod/dod-idx/harmonizing-music-as-a-discipline-in-constraint-logic.pdf). I see how the "open chords + strumming pattern" addition (which is entirely my own) to the original idea steers the thing a wee bit in an "arranger" direction, but I believe it could be interesting for end-users who work with pop styles *and* a relatively simple way of adding a second implementation to be worth at least throwing the idea in there. It wouldn't take very long to talk me out of it, though; it is already a stretch/optional goal. Regards -- Tobia Tesan <[hidden email]> <sip:[hidden email]> "Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves." -- 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
On 15/03/2016 00:04, Tobia Tesan wrote:
> I also seem to understand that the possibility of several > style-specific rulesets for voicing should be at least considered (but > I might have completely misunderstood Marc's point - please jump in :-). Not that I would turn my nose up at a simple static lookup table, mind you. I am trying to take a cue from what I read on the chan; In this respect I would love to know what the project maintainers think, in terms of scope of the project, etc. Good night. -- Tobia Tesan <[hidden email]> <sip:[hidden email]> +39 393 4427709 ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
Tobia Tesan wrote: > I don't think that the use cases for Band In A Box and similar > "arranger" software and the "chord playback" idea from > https://musescore.org/en/developers-handbook/google-summer-code/ideas-2016 > are *exactly* the same, though. Point taken. I'm just a lurker, not a developer. I was just suggesting something less hard-coded might be beneficial in the long run.> In this respect, a set of 4-note voicing rules appears, in my uninformed > opinion, interesting both for its practical results and as a relatively > straightforward "proof of concept"; there seems to be some literature > about modeling that kind of problem If you're talking about SATB voice leading, I think it's one of those things that initially sounds good, but in practice turns out to me much less so. At least, that's been my (limited) experience. The main issue from a musical perspective is that the "rules" are there to ensure that each melodic line is independent, and that dissonances are prepared and resolved in a style-appropriate manner. But that's not the same as ensuring the results aren't dreadfully dull. On Mon, Mar 14, 2016 at 5:09 PM, Tobia Tesan <[hidden email]> wrote: On 15/03/2016 00:04, Tobia Tesan wrote: ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
I think from previous discussions there seems to be general agreement that the way forward is for any chord playback syste, to simply generate actual notes on an actual staff, the user could then edit or make that staff invisible etc. So there would really be no special MIDI implications. With this in mind, it would really be more like the current slash notation or "explode" facility - a command that takes a score and adds more notes to it somehow. I guess that means you'd need to re-run the command after any changes you made to the chords, which I might argue could be seen as a feature, although perhaps there could also be a prvosion to do this automatically each time you play the score (so much for ability to edit the playback, though - your edits would be lost on the next play unless made a copy). There are a number of algorithms that could be used to generate the voicings. We already parse the chord symbol in a way that gives us pretty good information about the structure of the chord, and I suspect we could find a usable algorithm to create a voicing that would work for guitar or piano. We could start with just whole notes, or adopt whatever rhythm is already present on the destination staff, so you could enter your own comping rhythm and have it followed, or perhaps we could add another command to generate appropriate rhythms. It has also been suggested we *integrate* with Impro-visor for more sophisticated playback, and I'm open to that as well. Marc On Mon, Mar 14, 2016 at 8:52 PM David Cuny <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
On 15/03/2016 04:18, Marc Sabatella wrote:
Thanks for you reply, Marc. > I think from previous discussions there seems to be general agreement > that the way forward is for any chord playback syste, to simply > generate actual notes on an actual staff, the user could then edit or > make that staff invisible etc. Ah, is it so? I think I have completely misunderstood you, then; sorry about that. In practice, this doesn't change a whole lot, though, I guess that instead of a "render to midi" pipeline stage you would get a "render to staff" stage. > There are a number of algorithms that could be used to generate the > voicings. Would please you have some pointers in this regard? More than the algorithmic stage I am not sure how the solution itself would be characterized, though (ie: what does it actually do, harmony-wise?). > It has also been suggested we *integrate* with Impro-visor for more > sophisticated playback, and I'm open to that as well. Could you elaborate a bit on that? What sort of "integration", exactly? Thank you very much. -- Tobia Tesan <[hidden email]> <sip:[hidden email]> +39 393 4427709 "I have not failed. I've just found 10000 ways that won't work." -- Thomas Edison ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
>> There are a number of algorithms that could be used to generate the Non-developer jumping in again. ;-)>> voicings. > Would please you have some pointers in this regard? > More than the algorithmic stage I am not sure how the solution itself > would be characterized, though (ie: what does it actually do, > harmony-wise?). * Notes should move as little as possible, so they don't distract from the melody. Stepwise motion is preferred. * Active tensions (7ths and suspensions) should generally be resolve via downward step. * Four is a good maximum for a right-hand voicing. For chords with more notes, you can drop less essential notes: 9th: drop the root, because the left hand is playing it anyway. Maj11th:
drop the root (it's in the left hand) and the 3rd (it's a dissonance
against the 11th). You can generally treat a G11 as Dm7/G. Min11th: treat as min7 or min9 13th: These are more complex:* Always include 3rd and 7th * Never include the 11th (unless it’s the #11) * Include 9th and 13th whenever possible These rules ignore what's in the melody - things get more complex if you start taking that into account. You can implement the above rules with the following algorithm: 1. Choose the notes of the chord, having no more than 4 notes (lookup tables are good, especially since you can also flag tension notes). 2. Where possible, resolve tensions (7ths or suspensions) of the prior chord using downward, stepwise motion. 3. Where possible, resolve the remaining notes using stepwise motion (up or down). 4. Keep the remaining notes in the middle register - roughly E3 to G4. 5. If there's a half-step between the top two notes of the chord, drop the one not resolving a tension down an octave. -- David On Tue, Mar 15, 2016 at 1:02 AM, Tobia Tesan <[hidden email]> wrote: On 15/03/2016 04:18, Marc Sabatella wrote: ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
On 15/03/2016 19:37, David Cuny wrote:
> > You can implement the above rules with the following algorithm: > > [...] Thank you, David. Invaluable tip. :) -- Tobia Tesan <[hidden email]> <sip:[hidden email]> +39 393 4427709 "I have not failed. I've just found 10000 ways that won't work." -- Thomas Edison ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
In reply to this post by David Cuny
> 3. Where possible, resolve the remaining notes using stepwise motion (up or down). I forgot one other really obvious bit: not moving a voice is preferred to moving it. So:3a. Keep notes common between chords. Because of the rule to resolve things in a downward direction, you'll find that chords over time tend to creep downward. The solution is to apply the "keep notes in the middle register" rule to correct this. In any event, piano chord voicing really is a different thing than SATB voicing. On Tue, Mar 15, 2016 at 11:37 AM, David Cuny <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
Those are indeed good tips. Other things to consider include the fact that we can't assume the left hand is playing the root - what we generate should probably include the root in the bass. Perhaps in a separate voice to make it easy to remove. Also, we generally don't want to get into a situation where we have an extension rather than a chord tone as the next-lowest note after the root. I actually think we could likely get good results with a relatively simplist algorithm based on treating the piano kind of like a guitar, but one tuned to something like say C-G-C-E-A-D, always putting the root on the bottom, a chord tone next, and striving to keep low "fret" numbers for the remaining notes. Marc On Tue, Mar 15, 2016 at 12:54 PM David Cuny <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
> Other things to consider include the fact that we can't assume the left
hand is playing the root - what > we generate should probably include the root in the bass. I'd assumed that the left hand part was part of the realization. Specifically, the bass needs to be sufficiently low to act as a bass tone instead of just a low chordal note. And to cover all bases - obviously, G/D has a D as the bass, not the root G of the chord. > I actually think we could likely get good results with a relatively simplist algorithm based on treating the > piano kind of like a guitar, but one tuned to something like say C-G-C-E-A-D, always putting the root on > the bottom, a chord tone next, and striving to keep low "fret" numbers for the remaining notes. You would get fairly good results, but it wouldn't give you the smooth voice movement and resolution of tensions. If you look at the open string voicings for the guitar, they're basically of same form: 1,5,1,3 but starting on different strings. Start with the E chord with this fingering: 0-2-2-1-0-0 = E-B-E-G#-B-E == E Major If you keep your fingers on the same frets but move them up one string, you effectively have transposed the chord up a fourth (because the strings are tuned in fourths). The problem is that the 5th string (B) is tuned to a third, so you've got to compensate by shifting the finger on the 5th string up a fret: 0-0-2-2-2-0 = E-A-E-A-C#-E == A Major Perform the same transformation (move fingers up one string and shift one fret up on the fifth string) and you get the D chord. You've also got to wrap the note on the high E string down to the low E string: 2-0-0-2-3-2 = F#-A-D-A-D-F# == D Major Continue and you'll get the remaining chords G, C, and finally F, which is effectively a barred E form. If it wasn't for that darned B string, it would be a lot easier to see the pattern (but it would be a lot harder to finger the chords). It's not that the chords generated by your system wouldn't sound good - it's just that there's a bias toward particular voicings that may not be immediately apparent. Plus, it's probably as simple to write something that smoothly connects chord tones. On Tue, Mar 15, 2016 at 12:01 PM, Marc Sabatella <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
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. 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.
On Tue, Mar 15, 2016 at 3:50 PM David Cuny <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
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 <[hidden email]> <sip:[hidden email]> "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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
> 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 maximumfor 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 <[hidden email]> wrote: On 15/03/2016 23:29, Marc Sabatella wrote: ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
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 <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
> 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 <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: Hello, and: Chord Playback GSoC idea
|
|
In reply to this post by Marc Sabatella
On 16/03/2016 01:57, Marc Sabatella 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. With a hashmap of similar structure "short" can get very large before it starts being a problem :) The entries might be pre-generated programmatically, at least partially. Meanwhile, taking Marc's advice, I've created a forum post to hear what users think: https://musescore.org/en/node/102286 -- Tobia Tesan <[hidden email]> <sip:[hidden email]> "Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat." -- Sun Tzu, The Art of War ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
|
In reply to this post by David Cuny
Hi,
I'm also very interested in this topic. I just wonder if it shouldn't be too complicated to just have a priority for extensions (like root has lowest priority, fifth next lowest - third has very high priority and tensions are higher than root and fifth but maybe the 7th is more important than the rest etc.) and count the movement between two chords e.g. in semitones. Now you try to have the notes with the highest priority while having as little movement as possible. Probably by just using the old chord as a new starting point, look for possible fitting notes for the new chord, take out non fitting notes and look one semitone up/down, than two and so on until your list of non fitting notes is empty. Now you can check about the priority by first examine how many distinct notes the chord has (doesn't make sense to search for a root replacement, if you have a "standard" 3-tone chord) and try to eliminate the root for example. One could than fiddle around with the parameters of that algorithm to get a good sounding progression. What do you think about that? ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
«
Return to MuseScore Developer
|
1 view|%1 views
Loading...
| Free forum by Nabble - Scala forum | Edit this page |