johnameyer / harmony-ts Goto Github PK

Support for non harmonic notes such as passing tones, suspensions, pedal points. Something to think about is how this works with the current API only looking at vertical slices (incomplete/harmonized chord).

Probably this can be done in two steps - firstly supporting these as outputs and then secondly supporting them as inputs.

PartWriting Rules should be cleaned up to allow for more descriptive error messages, intuitive control of ordering (from the API), and more configuration in general

The harmonizer as it currently stands should be able to harmonize other major keys, but somehow loses its accidentals.

I viio7/ii ii should be possible using:

C5 Bb4 A4
E4 E4 F4
G3 G3 F3
C3 C#3 D3

The particular progression I6 viio6 I vi IV6 V43/V V takes a long time in the keys of Gb and F# but runs quickly in other keys.

As much as possible, items shared between expansions and progressions should be limited to one or the other (e.g. expansion [V appended with V7] exists but is also a progression of its own).

As a specific, because V7 was introduced before expansions there is support for knowing what comes next after V7, but for the most part it should just be the same as V and V7 should be looked up based upon that in the general case. In other cases the support might not be available.

The library needs to have understanding about modulation and short-term tonicization

• I - V/V - V
• i - V/III - III

Often the harmonizer will harmonize the second chord of a sequence using a different voicing or octave positioning of voices than the chord before the sequence. Certainly, it should be preferred (enforced?) that it be of the same shape and octave displacement as the preceding. It might be that a check needs to be done that the preceding chord is of the same 'shape' - i.e. hasSeventh and inversion - but it needs to be considered whether a counterexample is actually possible.

Example:

Am: i iv VII III VI iio V i

Cm: C4 Db4 C4 B3 C4

Attempts to use ii065 (incorrect) when it should use i64 or an applied chord

Currently, if a chord is not in the vocabulary, or the voice leading does not permit resolution of the constraints, the engine will attempt to harmonize all possible voicings before determining it is impossible. Instead a linear check should be done over the array to identify up-front that a progression is impossible before attempting to find voicings.

Might be useful to have rules like 'seventh must resolve down' to suggest notes to reduce the search space when those arise.

The library needs a way to indicate what sorts of progressions and chords should be enabled

Hi, I'm trying to harmonize a few chords but I get always errors like:
"Failed rule spelling on constraint <[0-9]>"
The chords should be harmonizable, so I wonder if I miss anything or maybe there is a bug.

const hr = require('harmony-ts');


var bassNotesPrim = [
  'E2', 'F2', 'G2',
  'A2', 'B2', 'A2',
  'F2', 'G2', 'A2',
  'C3', 'F2'
];

var bassNotes = bassNotesPrim.map(n => new hr.AbsoluteNote(n));

bassNotes[3]._accidental = hr.Accidental.FLAT;
bassNotes[4]._accidental = hr.Accidental.FLAT;
bassNotes[5]._accidental = hr.Accidental.FLAT;
bassNotes[8]._accidental = hr.Accidental.FLAT;

var levels = [
  'V65', 'I',    'V43',
  'I6',  'V42',  'I6',
  'I',   'vii6', 'I6',
  'V',   'I'
];

var scaleNotes = hr.Scale.NaturalMinor.notes;
var scale = [hr.Key.F, hr.Scale.Quality.MINOR];

var inRomans = levels.map(le => new hr.RomanNumeral(le, scale));

var i = 0;
var con = [];
for (i = 0; i < bassNotes.length; i++) {
	con.push(new hr.IncompleteChord({voices:[undefined, undefined, undefined, bassNotes[i]], romanNumeral: inRomans[i], flags: {key: hr.Key.F}}));
}

var partWriter = new hr.PartWriter();
var results = hr.flattenResults(partWriter.voiceAll(con, scaleNotes));
var bestResult = results.next().value;

I try to make the first bass note natural F although it's Fm scale and the other flat according the scale.

Thanks!

The rule for sequences currently allows a voice to be transposed by an octave from where it should actually be, which should not be the case in four voices.

Ex:
Cm: i v VI III iv

When a voice does make a leap, it should be followed by a step in the opposite direction.

The harmonizer currently has commented-out options that would improve its function.

When running the package test scripts, the results of where the most time was spent should be uploaded as an artifact to identify future improvements for speed.

The harmonizer should support minor key progressions

The library needs auto-generated documentation

The base classes like RomanNumeral, Note, etc. should have their methods documented, cleaned up, and potentially cached (for the readonly objects).

When an applied chord (V) follows a V in the home key, the harmonizer will sometimes choose to do an octave jump when it wouldn't make sense.

E.g. G: I ii6 V V43/IV IV6

Current the harmonizer supports up to about 50% of a Music Theory II course, but support of advanced chromatic concepts and other voice leading chords is eventually needed.

Rather than just selecting the first acceptable option, allow for the options to be ranked and the best to be chosen

Might still allow for a speed option of only generating the first N options

Allow for support and rule checking for implications of weak vs strong beats

• Chord repetition
  • Repeating a chord from a weak beat to a strong beat is to be avoided
  • This includes I-I or I-I6 (viio is considered same as V for this as well)
  • Unless it is repeated again on another strong beat
  • And unless it is the initial tonic
• Bass note repetition
  • Not repeating a bass tone from a weak to a strong beat while changing the chord it supports
  • But allowing for "dissonant suspension" IV-V42
• Cadential 64 Resolution

Before the harmonization engine should try to harmonize something, it should check that there are not any pre-existing part-writing problems that would cause it to fail, or that the given vocabulary is sufficient (this might be harder), and report to the user.

Initial thoughts:

When a user (or a bot) opens a pull request, I'd like to see -

If it is determined that it is not a breaking pull request (TODO determine how to do this), then apply a commit to bump the version and auto merge

If it would be a breaking change, then once approved and tagged, apply the version bump and then automerge

Rewrite find-solutions to reduce search space and decrease runtime

• follow doubling and spacing rules outright
• check for parallels
• ignore options with too large of leaps

Add support for expansions of harmony above a bass note and relevant rules behind those

• Cadential 64
  • V64-53
  • V864-753
• 5-6 Technique
  • I5-6
  • etc.

Currently we don't allow for loops in the expansions, though it is perfectly valid to have a progression like V/V V6/V V or V6/V V/V V, which could be repeated some number of times but doesn't make sense to have both be at different priorities. Maybe if it is only inversions there should be a different mechanism, but depending on other use cases this might be the right solution.

Follows up on #26.

Since the applied chord rules currently take the scale of the previous chord rather than the scale of the chord being tonicized, when the chord being tonicized is also a pivot chord this results in the applied chord being wrong. E.g. C: I V/vi F: vi V I, where vi is ii in C, is valid, whereas the applied chord should be V/ii in this style.

The engine still has a problem of, when deep in the voicings tree and coming upon an impossible state, will take gradual steps backwards in order to attempt to fix the problems, resulting in a massive amount of time spent solving the problem.

Examples:

• Before upfront checks an ending progression V ii GH-18
• Currently a descending bassline that could result out of range GH-44

This high-level issue tracks the status of these scenarios as they arise and considers how they all could be fixed.

With the current 1-1 mapping (in most cases) of laying out the available progressions, e.g. I - V, some possibilities are missed. Instead it should support more general predicates like 'any IV chord in root position'.

Add an action to automatically tag a release and publish to npm when master is merged into

I V43 I6
E4 F4 G4

Probably should also be extended to work with applied chords?

Consider supporting progressions from common modes (e.g. use of major IV in dorian) in some form.

Possible simple implementation might just boil down to some part-writing rule preferring use of borrowed chords.

There should be a way to indicate that a chord should be a cadence of some sort

Support for generating valid nonharmonic tones on top of existing harmonization

• Passing tone
• Neighbor tone
• Appoggiatura
• etc.

Using sequences in the web demo is pretty flaky - some examples work but others completely fail

Probably need to expand examples we have

The engine should have an understanding about the higher level of the harmonization it chooses, for example avoiding V-I outside of a cadence

E.g. doesn't know how to harmonize i viio65 i or I viio7/ii ii (demo using defaults)

CheckAll might be more efficient if some of the previous checks were combined together

• Checks for parallel and contrary 5ths
• Checks for LT and 7th doubling

Should some expansions be allowed to be chained? For example, the cadential 64 before or after a secondary dominant (I V/V I64 V)?

How to differentiate chainable from nonchainable?
What depth to continue to?
How to avoid cycles (e.g. V V6/V V could be infinitely repeated even though this should be handled externally)?

Currently the harmonizer will generate the same progression for a different voicing, causing all of the predicates to again be checked even though with current progression rules it is not possible for the result to be different. As well, part-writing rules that deal with a chord progression should be moved out to a level that is only checked on the progression level.

Child of GH-27

The current predicate-producer progression model, along with the expansion chainable operator model, offer a great deal of flexibility in generating chord progressions. However this flexibility prevents tabular lookup and prevents a simpler generation of chord progressions. If this was reasonably curtailed, the language could be lower on the Chomsky hierarchy and be parsed or generated more easily. Advanced voicing rules could be moved into the part-writing instead as was done with the Cadential 64 implementation.

Possible Restrictions Include:

• Removing scale from being passed in to operators
• No specification of voicing
• Purely operating off of the previous chord (or previous progression class GH-28)

The part writing rules (and perhaps preferences) should support handling of incomplete chords. This would allow for checks to be done at the beginning over the constraints to check that no problematic voice leading would result from those and for resolved constraints (rather than with all the parts filled in).

Child of GH-18

Use of Augmented 6th chords.

The rules currently get the overall gist of harmony rules, but there are some exceptions that need to be allowed for

Examples:

• Doubling rules can vary in regards to V7-I
• The parallels of I-V42-I6 and 3-4-5 in the soprano override the normal resolution of the seventh
• The seventh of V7 has different preparation rules than other 7s

The part writing engine should provide defaults for other common forms of voicing like block chords, arpeggiation, waltz style (oohm pah pah), etc.

E.g. should be able to provide just the notes instead of the note + octave, figured bass, etc.