Bb6 becomes Gm7 on MIDI Import

Hi,

Bb6 is a very common concluding tonic chord in the jazz idiom.

Indeed, the progression shown, ii V7 I  is probably the most important and common progression in jazz.  (Extensions and alterations are often also applied to any of these chords.)

So, to the point of analytical appropriateness, Bb is the key of the composition (file), Bb6 here is the tonic chord, it is the concluding chord, it is expressing the most common idiom in the genre, and it has been supplied to Synfire in root position.

Thus, there is every reason here to call a Bb6 a Bb6, and no reason to call it Gm7 or anything else.

--

I see it as essential for Library construction purposes that Synfire to be able to import Harmony from a file exactly as specified, just as if the user had typed the desired progression of Harmony into the inspector or dragged it one-by-one from a Palette.

Of course such input a specification file must follow some rule/format.   In this case it does.  All the chords in the file are supplied in root position. (The obvious, perhaps only, way do it.)

--

To provide the needed capability without perturbing existing behavior that also presumably has a constituency, I suggest a switch  "Treat Imported Chords as in Root Position: Yes/No" (or similar) to prevent Synfire from conducting undesired reharmonization/relabelization upon import.

Another way to go (and I recommend doing both) is for Synfire to be able to read in MusicXML files and convert the chord symbols therein to Harmony.   This would involve no interpretation of notes (block chords), as the chord symbols in MusicXML are textual, as written on a lead sheet.

--

I hope you can consider my motivation here as valid.

I am trying to build-out a comprehensive Synfire Harmony library, in 4m and 8m chunks, with roots in Jazz, sourced from the changes of hundreds of songs which provide a rich mine of material.

I'm doing alot of work in the background, along with others, sourcing the songs, representing their changes in MusicXML, and converting the MusicXML into root position block chord MIDI files for Synfire to import.

All this work comes to naught if Synfire insists that a Bb6 (as an example) is something other than a Bb6.

Please help me to expand the usage of Synfire in this new, modern, jazzy, direction. (I can't get there w/o you!)

Thank you.

Your suggestion may work but requires a deep look into the analysis code. The algorithm must deal with many genres and conventions. Most MIDI file imports do not contain straight chords (let alone in root position) but are a wild mix of instrumental performances where harmony has to be deduced from multiple instruments considered together.

In other words: Analysis it not data import. It always involves guesswork and assessments.

Yes, and perhaps they should be treated as different paths of ingestion.   Such a call can only be made by someone who knows the code well.  

But the user need (for both) is easy to express, and valid!

MIDI-to-Chord-Track operations are common (though not yet universal) in DAWs.  The equivalent in Synfire would be MIDI-to-Harmony.   When the MIDI is well quantized, you can get both Harmony and Figure in chunks (I've done it) - highly desirable!

From the UI point-of-view, maybe a checkbox "Import is MIDI Chords:  Yes/No".

However, there is a convenient way to import progressions with 100% precision. You do not even need to run a MIDI file import. Just copy/paste the chord names (separated by spaces) into the inspector. If you can export your progressions as a text file, that is.

But there is no duration info following this method, right?   (IOW, no way to indicate this chord is for a full measure, the next two chords are for a half-measure each, etc.)

Also, the aim is definitely for batch import here.

This is where MusicXML takes the stage.    In MusicXML the chords are symbolic, textual, but with placement and duration.   MusicXML was designed for this (and other things).     So, for Synfire to be able to import to Harmony from MusicXML files would be an excellent thing to have, and could be implemented separately from all MIDI analysis or data import.

If you can provide a list of formats Synfire should import harmony from, that would be very helpful. MusicXML is fine. MIDI requires very strict formatting to work. What else?

OK, I will look at that question and come back with more info/suggestions. 

OK, the world I'm most familiar with is the Jazz world.   As requested, looking to formats other than MusicXML where large resources of chord progressions (songs) are available, below are the major choices per my knowledge.

iRealPro files

iRealPro (iRP) is a very popular, widely-used program that creates accompaniment from leadsheets (chord progressions).  The Jazz library of iRP has 1410 entries.  (There are also libraries for Blues, Brazilian, Country, Latin, Pop).   Thus iRP is a huge source for leadsheets.

It would be possible for Synfire to directly import iRP native files.  The format is essentially textual, and is documented here:  (https://www.irealpro.com/ireal-pro-file-format/) .

As a program, iRP does export MusicXML, but so far not in batch/bulk.  The iRP libraries, known as playlists, do provide the leadsheet content in collated form.  IOW, one file contains the full 1410-item Jazz library.  (Likewise for the other libraries mentioned.)      

Impro-Visor files

Impro-Visor (IV) is a program from the academic side with publicly available source code which reached a very advanced state over many years of development before the death of it's primary author.  I could rave about how awesome this program is, but the present point is that it has a huge jazz leadsheet library in a simple textual format.  

The jazz leadsheet library for IV, known as the "imaginary-book" contains 2615 items, as separate .ls files.

It would be possible for Synfire to directly import IV native files.  The format is documented in a PDF found here:

(https://www.cs.hmc.edu/~keller/jazz/improvisor/LeadsheetNotation.pdf)

As an example, the relevant portion for harmony looks like this:

F | F/C | C7 | / | 
F | C7#5 | F | F/C | 
C7 | / A7 / | Dm | / | 
A/E | E7 | Am | C7 | 
F7 | / | Bb | / / Bb7 | 
G7 | / | C7 / C7b9 | C7 C7#5 / | 
F | F7 | Bb/F | Gm7b5 | 
F/C | C7 | F | Abo7 Gm C7b5 |

I've attached the a .zip of the "imaginary-book" to this post.

Attached is a Synfire library that (imperfectly) represents the goal here.

The content is the 1410 items from iRP.

The method of creation was by multiple-batch pipeline processing - 

1.  from iRP native to MusicXML
2. from MusicXML to MIDI file (.mid), block chords in root position
3. into Synfire Pro by hand, with Simple option into 4m chunks

( Steps #1 and #2 courtesy of Karim Ratib, and his projects ireal-musicxml and musicxml-midi.                       https://github.com/infojunkie )

This library is not bad.   One could begin to work with it.   But it is not fully accurate as intended.

The major source of "imperfections" is Synfire's insistence on not accepting more complex chords exactly as provided in the MIDI.   I will illustrate this in another post.

Here is the iRP chart for Blue in Green:

Our attention will be on measures 5-8.

The chords as provided make it into the MusicXML file (attached as .zip), like so (for the Bbmaj7#11 chord):

      <harmony>
       <root>
         <root-step>B</root-step>
         <root-alter>-1</root-alter>
       </root>
       <kind text="M7#11" use-symbols="no">major-seventh</kind>
       <degree print-object="no">
         <degree-value>11</degree-value>
         <degree-alter>1</degree-alter>
         <degree-type>add</degree-type>
       </degree>
     </harmony>

and the information also makes it into the .mid file (also attached).   

Unf. when imported into Synfire, we get this:

whereas the proper goal (created by hand) would be this:

So, yes, straight-ahead input of exactly specified harmony via .mid files would be something different than what Synfire currently does.    Could it be done?   Of course, it's software!    Would it be a major hassle, best avoided by taking another route?   Perhaps.

In favor though of being able to import MIDI to Harmony, exactly as specified, I note two cases.

Cubase will translate the given MIDI to it's chord track exactly as intended:

Studio One will translate the given MIDI to it's chord track exactly as intended: 

All I'm saying here is that Synfire, if it could do the same, would find itself in good company!

It's an ecosystem thing.   Such capabilities are implemented because people find them very useful.  The more they are implemented, the more useful they become (and the more expected).  It's a virtuous spiral.

So, in summary, I'd say there is more than one road to the same ultimate destination.

I find value in all of these roads, and so I advocate for them.

When my programs work together and/or work similarly, it is highly enabling, and satisfying.

When my programs interchange data seamlessly, it is highly enabling, and satisfying.

All of these roads (MusicXML, iRP files, .ls files, .mid files) towards exactly specified, batch importable Harmony are valuable, each on it's own terms.

Most important (IMO) is that at least one of them be opened for Synfire!   <g>

Such good news!   

Looking forward to the update.   Thanks very much!

Hi.

Thanks for the newly processed Library.

Is the new root position analysis in v 2.4.1 b2  turned on for the import by 'Complete Chords' in the Harmonic Analysis section?