BillBohan

I briefly experimented with procedural music generation many years ago and will relate my experience in the hope that some may find it interesting or take inspiration from it.

I had read the Byte magazine article called "A Travesty Generator for Micros." which works with text files and realized that Markov chains could be applied either to whole word or individual letters. Sufficiently long chains of letters almost always produce actual words. Sufficiently long chains of words generally produce complete (although nonsensical) sentences. Excessively long chains copy the input to the output. See [1] and [2]

At the time I was playing LOTRO [3][4] which uses ABC files [5] which are a text representation of music. I used the .abc files as input to the travesty program and got very interesting output. I used the rescan method which reads the input file for each note to output. It is slow but uses far less memory than the array method which reads the input once and generates a complete table of all transitions.

Running travesty on a single .abc file produces an output which is very similar to the input and only mildly interesting. Chaining together 2 or more input files is when it gets more interesting. It did not work well unless the input files had the same key signature.

I considered the possibility of transposing all input files to a common key signature but did not implement it. Nearly all music representation is an abstraction of the music. Music is generally quantized into notes of the even tempered 12 note scale. The tune is recognizable regardless of the instrument it is played on. I wondered whether there were further abstractions which could be used similar to the way that either letters or words could be used for text but am not sufficiently musical that I could discover them.

If you try this I think you will quickly get results which encourage you to continue.

While reading the article and the comments I realized that it will work perfectly in my NISC processor [1]. I just need to update my specification.

To extend the simple first specification to include multiply is very simple. I just need to have a MUL register which, when written, multiplies the written value by the value in the accumulator with the low part of the result being left in the ACC and the high part in the MUL register.

Extending to include integer divide is a little more complicated. I will have to add a DIV register and a DIVEX register. Writing to DIV will divide the value in the ACC by the value written leaving the result in the ACC and the remainder in the DIV register. DIVEX will contain the address of the routine to call when division by zero is attempted which means that DIVEX must be loaded before division is used. If I specify that DIVEX is initialized to zero by the hardware and that DIVEX==0 means that divide by zero leaves zero in the ACC and the remainder (former contents of ACC) is left in the DIV register then 1/0 = 0 will be the default behavior with the ability to change that behavior simply by writing the address of the divide exception handler to the DIVEX register.

I leave it as an exercise for the reader to determine how to deal with this in high level languages. I can fully support it in machine code and assembly language.

I would very much appreciate feedback and suggestions regarding my preliminary specifications which will be changing in the near future (before year's end) to include MUL, DIV, and floating point support. I really want to have a firm specification before proceeding with the VHDL implementation.

My strategy is to propose rule changes which allow every player with a nonzero score to be declared a winner.