Chord names changed

[csterritt]

From the "Dolphin Dance" demonstration file, at bar 26:

In the source, the chords are F# and B (in the json, they're chords 100 and 102). However, Scribe (evidently) feels they'd be better shown as "Gb" and "Cb". These chords are not changed (e.g., F# in bar 8 and C in bars 1, etc.). They should not be changed.

Also, as a "usage" thing, I'm very happy to see that you can just have a "C" chord with an empty string for the mode. However, at least in jazz notation, the triangle for major appears to only be used if it's a major-7 chord. "Ordinary" major chords don't have the triangle. I recognize that this may be different in different contexts, which is why I'm glad it's avoidable. Unfortunately, you can't give an empty mode in "shorthand" mode (maybe that should be a separate issue).

[stephband]

Both important points.

Scribe has a probabalistic auto-speller (in https://github.com/stephband/scribe/blob/main/modules/sequence/to-keys.js) that looks at surrounding context to determine how to spell things, and it is misbehaving. It may simply be a question of fine-tuning the initial weights in emissionMatrix, it may be that a different strategy is needed. I haven't experimented much with it so far but it needs to be played with. Whatever the case, there should almost certainly be a 'spellAsAuthored' option somewhere which would print as authored any untransposed music.

I agree with you about chords. These events, although called chord events, are not supposed to describe chords, they are supposed to represent a mode. I did hesitate to call them mode events, as that would be clearer intent, but I also think it's less understandable for less experienced musicians. To that extent, a "C" mode with no extension is not supposed to work! It's meaning is ambiguous.

Chord extensions in the data are actually mode identifiers, there should be some mechanism for end users to be able to spell them how they like them, so if an implementer decided they want to display "maj" instead of "∆" that should be possible, but the "∆" identifier in the data stays the same.

That's not to say I don't want to support display of chords symbols without extensions – I do – I'm just not too certain how best to do that. I am trying to do is to separate the representation of these concepts in the data from their final display, so I want to be strict-ish about what the data allows. Perhaps we should force "C" to mean a mode with no 7th in it. Definitely up for discussion.

[stephband]

I have created a seperate issue for the autospeller (#16). Please feel free to keep talking about chords here.

[csterritt]

Yes, I'm definitely a less-experienced musician :-) so thanks for the clarification! I was definitely talking about "common usage", rather than rigorously correct music notation.

I'm working on a tool to automagically generate "good enough" lead-sheets, so simple is best when you're trying to read something on the fly.

[stephband]

If you have anything to show I would love to see it. My intention was to build one myself. (I was going to use git gists as a storage mechanism. I have long thought that gists would provide a decent record of authorship, by which I mean: I want to make an arrangement of a tune that @csterritt has written, so I fork it – the record of where it came from, and what other arrangements exist, is preserved in the git history. It might be a dumb idea, but I think it worth a shot :)

so simple is best when you're trying to read something on the fly.

I consider that this should be the choice of the end user. They should be able to say to the UI, "show me no chords", "show me simplified chords", "show me chords with extensions", "show me chord extensions with brackets" (brackets being stuff in brackets, eg. F7(#11)). Or something along those lines.

[csterritt]

I think your fork-a-tune idea is brilliant!

And, yeah, eventually I'd like this thing to be an app where you can start with a .mid file, and customize everything. For now it's a shambling hulk of a proof of concept :-)

[stephband]

I don't know much about .mid, but there is no 'native' way to represent chords, is there? How would you go about that? In SYSEX messages?

[csterritt]

I'm getting my .mid files from chordify.net, which is a very cool service that takes a YouTube music video, analyzes the music to figure out what key it's in, what chords are used, and when. Then when you play a song on chordify.net, it shows a grid representing one box per beat, with chord names in the boxes where changes happen, and it animates a cursor going through it along with the song to let you play along. It's great for beginners like me.

SO: so far I've only analyzed a few of their .mid files, which have three tracks. The first is empty; the second is however many chord changes there are, with the three notes for each chord. The third is the bass line (...I believe...), it's just one note per chord, but if (for example) it's a G chord with a C in the bass, it's shown as "G/C" (which is typical for the kind of music I play). Typically, the bass note is the root of the chord; those are just shown as "A", or whatever. It shows minor chords, etc., as well.

Which is all a long way of saying that (A) I gotta figure out which chord to show for each set of notes, and (B) I think you're right, there's no 'native' way to represent chords. It's just three (or more) notes at the same time.

Since chordify.net has (possibly correctly :-) identified the key of the song, I can use that to help decipher which chord to use for a particular set of notes.

So I don't think my tool will be useful for 'general' .mid files, probably just chordify.net ones.

[csterritt]

Oh, and I keep forgetting to mention -- scribe is amazingly brilliant! I was talking to a friend today who's a web developer (I'm retired, but did web stuff the last 11 years of my career, and still do a bit for fun, hence this project). He was similarly gobsmacked at what you've been able to do, with 'just' HTML and CSS! Thanks! It's very cool, and definitely inspiring.