Data structure for storing chord progression rules?

A Markov Chain might be a good fit for this problem.

A Markov Chain might be a good fit for this problem. A Markov chain is a stochastic process where the progression to the next state is determined by the current state. So for a given interval from your table you would apply weights to the "Leads to" values and then determine randomly to which state to progress.

– Michael Jasper Sep 30 '11 at 17:10 I've implemented it for text by creating a MarkovChain class which wraps a Dictionary> and a string Current.In this case, a key is the current state and the List are next possible states. This worked in this instance because values in the List were not unique and therefore I could use a bounded psuedo-random number to get the next state. – rtalbot Sep 30 '11 at 17:20 Oh - and yes - like the 1st order matrix.

– rtalbot Sep 30 '11 at 17:26.

It sounds like you want some form of directed, weighted graph where the nodes are the chords and the edges are the progression options with edge weights being the progression's likelihood.

Interesting read: It looks like there is an implementation of Directed Weighted graph objects in C# – Michael Jasper Sep 30 '11 at 17:06.

I'd expect you to have less than 100 chords, therefore if you use 32 bits to represent probability series (likely extreme overkill) you'd end up with a 100x100x4 (40000) byte array for a flat Markov matrix representation. Depending on the sparsity of the matrix (e.g. If you have 50 chords, but each one typically maps to 2 or 3 chords) for speed and less importantly space reasons you may want an array of arrays where each final array element is (chord ID, probability). In either case, one of the key points here is that you should use a probability series, not a probability sequence.

That is, instead of saying "this chord has a 10% chance, and this one has a 10% chance, and this one has a 80% chance) say "the first chord has a 10% chance, the first two chords have a 20% chance, and the first three chords have a 100% chance. " Here's why: When you go to select a random but weighted value, you can generate a number in a fixed range (for unsigned integers, 0 to 0xFFFFFFFF) and then perform a binary search through the chords rather than linear search.(Search for the element with least probability series value that is still greater than or equal to the number you generated.) On the other hand, if you've only got a few following chords for each chord, a linear search would likely be faster than a binary search due to a tighter loop, and then all the probability series saves you calculating a simple running sum of the probability values. If you don't require the most staggeringly amazing performance (and I suspect you don't -- for a computer there's just not that many chords in a piece of music) for this portion of your code, I'd honestly just stick to a flat representation of a Markov matrix -- easy to understand, easy to implement, reasonable execution speed.

Just as a fun aside, this sort of thing lends itself well to thinking about predictive coding -- a common methodology in data compression. You might consider an n-gram based algorithm (e.g. PPM) to achieve higher-order structure in your music generation without too much example material required. It's been working in data compression for years.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.