Harmony Factory: Keep Harmonic Rhythm

I'll add also that 'Randomize Harmonic Rhythm' would be very nice to have too, as an alternative to a continuous line of chords all of the same length.

If we added rhythm to the mix, complexity would explode by an order of magnitude.

I don't see what you mean here.   Complexity for the programmer?   Complexity for the user?

I may be missing something here, but offhand I don't see great complexity in either case.

Both pictures above are "a list" of chords.   The top one is a list of 8 chords, the bottom one is a list of 6 chords.   The real difference is that in the top one all the chords are 1m in length, whereas in the bottom one two of the chords are 2m in length.     

The request to check a box 'Keep Harmonic Rhythm' does not mean that the infinity of all combinations of varying note lengths comes into play.    It means only that all the lists generated by the Factory are configured with the single specific set of chord lengths that the user has chosen (e.g. 2 1 1 2 11 as shown).

IOW, the user knows what chord lengths are desired from the Factory, and has told it.  Outputting the generated lists with those lengths should not be a big deal.

Consider the alternative:   All the progressions generated by the Factory are wrong (chord length-wise) wrt. their intended use, and will need to be edited by hand, one-by-one, before they can be used at the point where they are needed.   It is just this sort of labor that computers are meant to relieve us of!

FWIW, there are other chord generating softwares that have 'Keep Harmonic Rhythm'.  It's not a complex idea, or even a particularly complex implementation (if I may say so).   But it is very useful!

While it would be very slick (and desirable) UI-wise if the 2nd picture above (once prepared by the user) could be "injected" back into the Factory to guide it's further generations, a less-slick implementation could be simply as follows.

Instead of only having one field:

Chords:  <# of chords>

Have 3 fields:

Chords:  <# of chords, N>
Length:  <total # of measures, L>
Pattern: <set of N numbers adding up to L>

Example:

Chords:  6
Length:  8
Pattern: 2 1 1 2 1 1

The Factory then would just generate 6 chords, exactly as it does now, and then at the end make the simple change of setting the length of the first and fourth chords to 2m instead of 1m.

Orders of magnitude more complex?   Nah.

I apologize if I didn't express the simplicity of the concept very well to begin with!
 

Well, the Factory is applying rhythm to arbitrary chord progressions, every one it generates, and that rhythm is [ 1 1 1 1 1 1 1 1 etc.].

You listen to the chords and feel that some chord may be sustained longer and another may imply a short transition to the next. That makes you drag a rhythm accordingly. You will most likely end up with a different rhythm for every list of chords.

I quite agree with this as a good description of working "harmony first" (e.g. as when just listening to how it sounds on a piano).    Later, having finished the Factory-provided progression by assigning rhythms using this process you will let "the band" realize a "groove" over time within the time-unfolding bounds of that Harmony.  This is one great way to work.

There is another way to work that is almost completely opposite.  In this 2nd way, "the band" has already realized a "groove" over time, with a structure of Verses, Choruses, Breakdown, etc. expressed in "chunks" which are defined by specific lengths in time and also delineated by fills, different Figures, and other aspects of performance.  

In this way of working, you would have, say, 4 minutes of music entirely laid out, and you will have never listened to more than a single harmony/chord (e.g. Fm7) while doing it.   In fact, you can construct a fine piece of music this way with a completely static harmony.

Now, suppose at this point you want to use changing Harmony to expand the musical nature of the piece.

OK, the structures are all already defined.   What's needed is matching chord changes, by which I mean structurally matching chord changes.   Ergo, user states the structure, Factory provides!

I'd much rather Synfire didn't say:   "Nope, you are not allowed to work this way!"

Or, almost as bad (if more accurate):  "You can do as you please, but the obvious means of support for the workflow you describe are not going to be provided!"

Much better, IMO, would be:  "Ah, that's up-the-hill backwards from the way we've thought of it so far, but we see the approach you're taking, understand the request, and can probably work it in at some point."

Thanks for your replies, and for considering this.