Okay…apologies for the delay…I was busy, but also was uncretain whether I understood the material myself, that stopped me from saying more. Additional disclaimer: I’ve tried my best to pull out all the melody and counterpoint related content of the theory to leave things chordal. I’ve savaged the original theory in the process. Apologies to all affected by my act of gross violence.

Prolongation Trees

Okay, so what is a prolongation tree? They look like this:

So basically it looks like a time-span reduction with three different types of vertices.

The lines represent chords, and the coloured vertices¹ between them tell you roughly what the type of the progression is.

An aquamarine one means that there is no change between the chords represented by the two branches essentially repeats itself. This is called a strong prolongation. Given two chords that are the same repeated, the initial one is the dominant one, so aqua vertices almost always branch to the right (except sometimes in the case of up-beats and the like).

In the first diagram, we can see that chords 1 and 3 must be the same.

A blue vertex represents a chord progression where there’s only a little difference between the two, say a change in inversion, possibly the addition of a note to the chord². This is called a weak prolongation.

In the diagram, we can see that chords 1 and 2 must be only slight modifications of eachother.

All other forms of chord progressions are just given boring old black vertex, and called progressions.

Interpreting these in terms of relaxion and tension-building, we have the following diagram

Well-formedness and Suggested Shapes

What sort of trees are allowed?

Firstly the trees must be planar, so shapes like the following are not allowed:

Normative Prolongational Structures

Lerdahl considers the following pattern to be more or less a good ‘top level’ for trees, and calls it his prolongation basic form (with the suggested chords at the bottom):

Note that this doesn’t mean that there’s a I-V-I progression in the piece necessarily, it means that at the highest level or oranisation, The piece is oriented around the sequence of chords I-V-I.

Lots of pieces he analyses have strong prolongations at the top vertex instead of weak ones: you can take your pick I guess.

Two slightly more elaborate forms he gives that might serve as useful skletons are:

Either of these can be called the normative prolongational structure. The first has a minimal tensing-relaxing pattern, the second has a repetition of the opening)

Before I describe his two other guidelines⁴, I should say that the context in which I’m presenting them is the one where you are generating a prolongation tree from the top down, and trying to decide what additional branches to add.

For instance, say I’ve decided already on the prolongation tree below in back, and am trying to decide where I should attach a new branch, c.

The green lines represent allowable attachments, the red lines ones that are simply not (because I’m trying to add branches in a hierarchical manner, I’ve already essentially decided that either b or d must dominate c).

The Balance Constraint

If you’re adding brances that are framed³ by a weak prolongation, prefer to have the same number attached to each branch.

The Recursion Constraint

This is a rule advocating alternate left/right branching of progressions as opposed to repeated branchings in the same direction, though allowing for repeated branching in the same direction provided progressions alternate with prolongations.

In the following diagram, green branches are good, red are bad.

Here’s an illustration from the book

Interaction Principle

Say I am looking to add a branch at c to the following

and to attach it like this:

The recursion constraint says that if the chord I put at c is the same as the one at a then I must rearrange the tree and put in an explicit strong prolongation:

This is the only way that adding a new branch is allowed to interfere with the existing branches of the tree. Though it’s called the recursion constraint, it isn’t to be applied recursively.

I guess, if you were trying to add chords to given tree (which is the application I have in my mind here: a program generates a tree, then generates a chord sequences from that tree, then generates some music with that chord sequence), you want to avoid this happening.

Notes

It’s not necessary (or necessarily advisable) that one construct a single tree encompassing an entire piece, one could have a group of them, one for each phrase, or section. If your pieces doesn’t have harmonic changes every beat, however, a single tree could suffice for, say, a 16-bar section.

¹The blue vertices should be notated with black circles, and the aquamarine ones with similarly-sized black dots, but I can’t easily draw them at the moment for some stupid reason.

²In the original a weak prolongation is used when the chord stays the same but either the melody or the bass change a note. It might be worth testing my suggestion though.

³Note the word ‘framed’, the balance constraint doesn’t say anything about branches that aren’t directly enclosed by the prolongation.

⁴These are not strict rules, but I think for a basic generative model it’s appropriate to enforce them strictly.

Okay, I’m tired again. Have to stop. I’ve hope given enough, and in unambiguous enough a manner, that you should at be able to generate grammatically correct prolongation trees (there’s still going to be a lot of choice/randomness involved in the generation, it’s something that should be possible to refine easily enough if you find it lacking). Filling them out shouldn’t be too hard in principle…I’ve sort of hinted at how to do it already…but this is enough for one post…

Duplicated from here. The content diverges somewhat from Lerdahl.

I couldn’t find any nice stuff on-line, but I’ve been meaning to properly go through this stuff myself for a while, so I’m happy to have the excuse to learn something about it (Disclaimer: all of what I’m saying is a filtered version of what Lerdahl says in his book, both through my misunderstandings, and my understandings of what might be useful to Muku in his PG music program (This is primarily a response to a request made by him for info on this stuff, but of course I’d love if other people were to chip in and comment)).

TIME-SPAN REDUCTION

So if we have two chords, A and B, say, in progression, Lerdahl puts them into a special type of tree according to which seems to be the stronger of the two, (“a right branch signifies subordination to a previous event, a left branch to a succeeding event”).

Given a sequence of chords we can iterate this procedure (which I’ll outline in more detail later), using the prominent chords we had initially as the basis for a second level of calculations. One can end up, from a progression of chords A,B,C,D,E (not notes, just letters that could be any chords!) with a tree such as the following

“The most stable event in a segment is its ‘head’, and other events in the unit are elaborations of this head. Each head goes on to the next larger segment for comparison against another head, up to the level of the whole piece”

This is called a time-span reduction of the original chord sequence. You can ‘read’ it roughly in terms of tension: because A dominates B and B dominates C, we have a slight relaxation for the first three chords before D introduces us to the final chord, E. Looking it at a higher level of the tree, we could say that the whole piece is structured around the two chords A and E, around which the others are elaborations.

Each level of the tree looks at the progression on a particular time-span (in this case, B and C together would last as long as A). This photo of an example from the book might make it clear to those who can read score:

Actually, here’s the whole page: the original piece is at the top level, and the Three bottom lines represent ‘outlines’ of the piece at various levels of the tree:

Obvious questions the first: how do you compute which of two given chords in a pair is stronger than the other?

Brief answer (I can give a formula later): you look at the two chords, try and associate an appropriate scale to them, and see which of the two is more closely related to the tonic chord of that scale. (This is according to his model anyway: it doesn’t seem like a bad idea).

Obvious question the second: how might this be useful for generating music? Well, the tasty stuff happens not with time-span trees but rather with prolongation trees…which are like time-span trees, but they store more harmonic information…which come next…he gives a (simple!) grammar as to what tree-structures are more ‘musically reasonable’ than others. Using these rules, you could generate a tree pretty easily, and then populate it with various chords that are subordinated to eachother in the appropriate manners, which should, ideally, give you some sort of nice large-scale harmonic structure.

So…anyone any comments or queries? This isn’t a tutorial, so I didn’t aim for too much rigor, just enough to get a discussion going ;)

(I should be able to say enough about prolongational structures in one post that it’ll be possible to try set up a prototype. If it’s wanted).

Here‘s a simple playing by me of a chord-sequence that it produced. Here‘s a midi example that it produced by itself when I had it more developed.

There’s still a reasonable amount of work to be done on it, but it’s at a stage where it’s presentable.

Anyway, the current version of the haskell source code is here. Hopefully I’ll have more developed versions up in the future.

The source file is here. To produce a major scale in ghci, do something like the following:


:l miditest
createMidi "test.mid" [50,52,54,55,57,59,61,62]


I even managed to do something useful with this sort of code, that I’ll post some time in the near future.

5 Waltzes ( ps | pdf )

Anyway, the point was to try and be a little bit lyrical, and I don’t think I fell flat on my face (saying that they’re not particularly inspired lines).

And the second piece, which I have, I think, almost no time for excepting an odd rhythmical artefact that people might notice in bar 9 that doesn’t occur in bar 11, even though they are precisely the same. Unless my playing’s deteriorated to the extent that I have developed some accenting pathology. I should be able to have more fun with this effect in future (I’m not saying that it hasn’t been done before; it is, however, something that as an effect is new to me).

Lullaby ( ps | pdf )

Oh yes, now, without committing to anything, I wish to explain that though these pieces are rather a further step down the path of the trivialisation and miniaturisation I have tried rather hard to avoid, I had not put much time in to writing music when I wrote them and, as such, these are my just desserts, but that they do not in any event signify where I am going, nor where I wish to go, merely that I am, in fact, at least so obliging to myself so as to trundle along doing something where I can.

And, for those of the world with an interest in what I’ve been doing musically in the month or so since I wrote these things; I have put together several rather more substantial (but still, alas, miniature) pieces. They’ll find their way here in their own good time. Trying to become more harmonic. Succeeding, I think, but I’m going to have soon to make some concerted efforts to introduce some rhythm and polyphony else ways I’ll end up writing pseudo-chorales for the rest of my days, and then where would I be?

Also, prepare yourself for a JOKE, tomorrow, courtesy of a clarinettist.

However, one can still apply most of the rules quite well if we make things a little bit abstract and no longer require the above relationship [a,b]+[b,c]=[a,c] to hold, but rather that it hold only up to a certain constant interval I.

And what’s the sense in this? Well with this you still have three melodies, only now instead of all three being contrapuntally amenable, we have that any two of them are. I haven’t seen this expounded elsewhere, and given how practical it seems I thought I’d mention it here.

And why the devil did I want to mix up Fuchs with cohomology? Well, I was trying to figure out an easy example of a Gerbe :) (I failed, as it happened, but it’s quite teasingly close!).

And why this rambley ramble here as opposed to something more deliberate? Because I’ve been meaning to post this since November last year, that’s why. So this means I get to relax about it now. Chill, you know? And if anybody should wish for any explication I would be Only Too Happy to provide it.

So first three light pieces. The first I threw together today and am more or less ok with, insubstantial as it is, the other two are my first efforts from last October when I was making the transition from thinking about modulations to trying to write music. I had a bunch of other modulatory snippits that were short, but occasionally quite nice; alas I don’t really have the skills to extract cohesive musical works from them at the moment.

Ok, so, then:

Piece 1 ( ps | pdf )
Piece 2 ( ps | pdf )
Piece 3 ( ps | pdf )

And, only slightly more substantially, a sonatina; weak, and almost certainly a dead and, indeed, rather clichéd end, but I do like some of the sounds it in.

Sonatina ( ps | pdf )

Sonata #2 ( PS | PDF )
Prelude ( PS | PDF )

Seven Preludes ( PS | PDF )

Basically, say we had a scale, and a gradus suavitatus on that, a measure of consonance, so that given any two intervals, you can say if one is more consonant than the other. Now given two scales, it might be a worthwhile thing to look for things that preserve relative consonance; that is to say, a function f from one scale to another will have to satisfy the rule a>b => f(a)>f(b).

So, I wrote a program to do it. No interface yet, it’s to be run from within ghci; specific details of how to use it are given (in a very rambling sort of way) at the top of the source code. It seemed like it might be most useful in looking for interesting transformations of melodic motives that have a small number of notes. However, I can’t say I have been able to do anything useful with it, alas.

For an example of the program’s output, see this file:

Harmony-preserving maps example ( ps | pdf ).

For the code itself, here’s the source file:

Harmony Preserving Maps Generator V0.1 ( hs )

So yeah. Out.