Lerdahl – increpare games https://www.increpare.com let's try something out here... Fri, 18 May 2018 22:16:47 +0000 en-US hourly 1 https://wordpress.org/?v=4.8.2 Lerdahl, part 2 https://www.increpare.com/2008/11/lerdahl-part-2/ https://www.increpare.com/2008/11/lerdahl-part-2/#comments Fri, 21 Nov 2008 02:20:23 +0000 http://www.maths.tcd.ie/~icecube/?p=835 This is a sequel to this post on Lerdahl’s GTTM.

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:

prolongation1-1.gif

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

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

strongprolongation.gif

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.

strongprolongationgifweakprolongati.gif

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 chord2. This is called a weak prolongation.

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

progression.gif

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

lefttoright.gif

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:

notallowed.gif

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):

basicform.gif

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:

normativeblah.gif

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 guidelines4, 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.

allowable-1.gif

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 framed3 by a weak prolongation, prefer to have the same number attached to each branch.

balanceconstraint.gif

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.

recursion.gif

Here’s an illustration from the book

bookimg.png

Interaction Principle

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

interaction1.gif

and to attach it like this:

interaction2gif.gif

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:

interaction3.gif

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.

1The 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.

2In 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.

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

4These 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.

]]>
https://www.increpare.com/2008/11/lerdahl-part-2/feed/ 1
Lerdahl, part 1 https://www.increpare.com/2008/11/lerdahl-part-1/ https://www.increpare.com/2008/11/lerdahl-part-1/#comments Tue, 04 Nov 2008 12:22:44 +0000 http://www.maths.tcd.ie/~icecube/?p=785 (serialized from this tigsource thread)

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”).

diagram3.png

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

diagram4.png

“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:

scoreshot.jpg

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:

scoreshot2001.jpg

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).

]]>
https://www.increpare.com/2008/11/lerdahl-part-1/feed/ 1
GTTM-based Chord Progression Generator https://www.increpare.com/2008/11/lerdahl-based-chord-progression-generator/ Sun, 02 Nov 2008 22:23:05 +0000 http://www.maths.tcd.ie/~icecube/?p=801 I’ll be posting some articles about the theory of Lerdahl very very soon. In anticipation of them (and to put something up so I can submit it to the Haskell Activity Report), here’s my implementation of a toy-model based roughly around his theory. It’s restricted to the process of chord generation.

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.

]]>