Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1314204 Posts in 58911 Topics- by 50030 Members - Latest Member: viktorhurskainen

September 19, 2017, 07:03:53 am

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Lerdahl, chords, and the like
Pages: [1]
Print
Author Topic: Lerdahl, chords, and the like  (Read 10453 times)
increpare
Guest
« on: October 10, 2008, 05:01:21 pm »

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 Wink

(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).
Logged
muku
Level 10
*****



View Profile WWW
« Reply #1 on: October 10, 2008, 06:08:49 pm »

You rock. Thanks for typing this out just for me Beer!

So, to put it another way, time-span and prolongation trees are the same concept, just once used in an analytic way and once in a synthetic way?

I would love to hear more technical details on the construction of such prolongation trees (which is of course the more interesting concept of the two to me because of my PG ambitions).
Logged

The Cosyne Synthesis Engine - realtime music synthesis for games
increpare
Guest
« Reply #2 on: October 10, 2008, 07:08:07 pm »

So, to put it another way, time-span and prolongation trees are the same concept, just once used in an analytic way and once in a synthetic way?
no. they're both equally analytic, I just didn't want to define them all in the one evening  :D

EDIT: OH WAIT you meant that one could be used for analysis, and one for generation?  Hmm.  In this case, yeah: prolongation trees are I think more potentially powerful when it comes to that.
Logged
agj
Level 10
*****



View Profile WWW
« Reply #3 on: October 11, 2008, 12:19:23 pm »

I know virtually nothing about musical composition, but that sounded easy enough to turn into code. Hope you do some experimenting with it, muku.
Logged

increpare
Guest
« Reply #4 on: October 25, 2008, 08:52:25 pm »

Okay...apologies for the delay...it was business, but also uncertainty as to 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. 

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



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



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.



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. 

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

I might try and code a basic prolongation tree generator if I have time tomorrow.  We can compare implementations maybe
« Last Edit: October 26, 2008, 12:51:37 pm by increpare » Logged
increpare
Guest
« Reply #5 on: October 26, 2008, 03:14:29 pm »

I wrote up what I think is a correct encoding of the various rules and patterns above (though not the interaction principle), though in haskell.  Enough to check if a given tree is in an admissable form.  It's here (in Haskell).  I had trouble encoding the Balance Constraint in a nice way :/
Logged
muku
Level 10
*****



View Profile WWW
« Reply #6 on: October 26, 2008, 04:44:07 pm »

Wow... great effort. I haven't read it yet, and I have a nasty headache right now so I won't just yet, but I will make sure to return to this soon. (Soon probably being November as things are a bit hectic at the moment anyway.) Huge thanks so far. I'll hopefully also try my hand at an implementation in due time.
Logged

The Cosyne Synthesis Engine - realtime music synthesis for games
increpare
Guest
« Reply #7 on: October 26, 2008, 04:56:59 pm »

Wow... great effort. I haven't read it yet, and I have a nasty headache right now so I won't just yet, but I will make sure to return to this soon. (Soon probably being November as things are a bit hectic at the moment anyway.)
It's been pretty good for me as well.  I honestly wasn't at all sure I understood what was going on right until I finished the haskell thing.   I think I've a reasonable grasp of it now.  So it's already paid of for me as an exercise, whether or not you get time to glance at it any time soon.  (I'll probably leave the third part for a couple of weeks anyway).

Quote
Huge thanks so far.
You're entirely welcome.  Grin
Logged
increpare
Guest
« Reply #8 on: October 29, 2008, 02:42:58 pm »

Here's some preliminary output from my program (played/arpeggiated by me, which certainly distorts things a lot, alas).  It doesn't have any tonality or chord-shape related stuff programmed in, only consonances/dissonances, yet.  However, that should be enough to furnish my next game with a soundtrack, I think...
Logged
muku
Level 10
*****



View Profile WWW
« Reply #9 on: October 29, 2008, 02:56:57 pm »

This is very, very cool. To my ears that sounds quite a bit more interesting than what my music generator a while back produced, even in this rough form. I can't help but wonder what your chord generator and my genetic algorithm for melodies put together would sound like, though... Wink This must be investigated. How much work was this to implement?

It sounds like some of the voicings are quite tight, to the point where they might sound dissonant when played as chords instead of arpeggios. Is this inherent with the algorithm? I would suppose that such things can be tuned.
Logged

The Cosyne Synthesis Engine - realtime music synthesis for games
increpare
Guest
« Reply #10 on: October 29, 2008, 04:23:13 pm »

Cheers dude.

It sounds like some of the voicings are quite tight, to the point where they might sound dissonant when played as chords instead of arpeggios. Is this inherent with the algorithm? I would suppose that such things can be tuned.
The chord-types are completely randomly selected combinations of four notes, which explains the clustering.  Relative dissonance of chords is accounted for, but I have no a priori caps on absolute dissonance.  I have a 'randChord' function that can be easily fiddled with though to change what chords are allowed.

Quote
I can't help but wonder what your chord generator and my genetic algorithm for melodies put together would sound like, though...  Wink This must be investigated.
If you could get your prog to accept chord sequences as input (either piped, or in a text-file), it might be quite amusing indeed to script them together*  Smiley.  I could easily output a sequence of four chords in the following format:

0 4 7 12 , 0 3 7 12 , 5 9 12 17

would represent C->cMin->F, say. 

Quote
How much work was this to implement?
The code was reasonably tough to write.  A little over 800 lines of quasi-idiomatic haskell (I've been toying about with haddock this evening, so you can browse it here (it needs tidying up and commenting)). 

I suspect it might be somewhat more awkward in a language less amenable to traversing about trees (I suspect I would never have gotten it finished had I tried it out in C/C++).

*I'm actually going to try to figure out how to do exports so I can interface the stuff with a C game I'm working on, but...that might take FOREVER, so some nice wholesome piping or file I/O is definitely the preferable.
« Last Edit: October 29, 2008, 04:48:07 pm by increpare » Logged
increpare
Guest
« Reply #11 on: October 31, 2008, 10:09:56 am »

Got midi output working today.  Here's an example of something more directly chordy, where I restricted the chords to being slightly more harmonic.  It scored the highest out of a batch of 100 candidates.  (The tempo is a bit fast; the fact that it has some melodic/motivic character isn't entirely...the point). 

One of the 'bugs' I'm going to have to fix is the thing you hear with the sequences of chords rising up a lot...my chord inversion formula needs some fixing.
Logged
Skofo
Level 10
*****



View Profile
« Reply #12 on: October 31, 2008, 02:08:57 pm »

OP got buleted?

I smell a conspiracy.
Logged

If you wish to make a video game from scratch, you must first invent the universe.
increpare
Guest
« Reply #13 on: October 31, 2008, 02:13:37 pm »

I smell a conspiracy.



 Huh?
Logged
Skofo
Level 10
*****



View Profile
« Reply #14 on: October 31, 2008, 02:50:56 pm »

Another odd thing is that the thread name shows up backwards on the index.
http://bayimg.com/LAlffaABL

Is this happening to anyone else? (Sorry for hijacking your thread, temporarily.)


Huh?
Holy shit it's writing backwards!

EDIT: At least it does when writing/editing the post... You changed your name to an East-Asian character aligner?
Logged

If you wish to make a video game from scratch, you must first invent the universe.
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic