Well, the Workshop on Algorithmic Computer Music has finally come to a close. The presentation went well and I feel that my project was well-received.
- Played around extensively with neural network/genetic algorithm combination
- Developed test for GA convergence
- Decided that the genetic algorithm was NOT converging with neural net fitness functions...abandoned the whole darn project and got a new idea
- Finished L-system engine
Well, my new direction is a much simpler one. Basically, I'm going to try to use L-systems for percussive pattern generation. In other words, an L-system drummer.
Spirit is a new generative module designed to provide lead parts. Spirit operates on a hybrid algorithm with a paradigm similar to that of the partial idea stream idea that I brainstormed a few months back. It also exploits the ease-of-use of the new XIAS library.
Three separate "streams" power Spirit: control, config, and duration. The control stream tells Spirit how to behave - that is, whether to use arpeggiation, single notes, or chords. The configuration stream provides details that determine individual pitches (or words, in the case of the control stream requesting a grammar engine). Finally, the duration stream is exactly what one would expect - duration information. Separating the duration stream from the streams that control pitch allows the module to uphold a degree of rhythmic consistency. This is similar to the way that I separate the melodic and rhythmic seed strings in Fraccut to make rhythm and pitch somewhat independent.
Right now Spirit is making effective use of both the L-system and grammar engine features of XIAS. Great - and unique - results have already been obtained even with a very rough version that made use of only three control types and three config types. Sample 11 on the sample page showcases this early version of Spirit and promises much more to come!
Some long-term goals for Spirit:
- Develop "character" - distinct styles that vary with configuration
- Restricted grammars
- Beat emphasis
- Markov data (as a supplemental "weight" in decision-making)
- Global variables
- Restrict algorithm types among configurations
- Production rules (L-system)
- Make effective use of all algorithms available in the XIAS engine (perhaps with the exception of the evolutionary engine, as it seems inapplicable)
- Strictly obey the instructions of the coordination module
- Achieve a level of creativity above that of any other generative modules
- Achieve a level of coherence above that of any other generative modules
In keeping with the spirit of the recent drive to create a "generalized" algorithm system (starting with the XenCut fractal cutting engine mentioned a while ago), I'm beginning yet another grammar engine. The goal this time? Lighter and more portable than WordEngine. Easy applicability, easy conversions between words and soft patterns of notes, etc. The engine will also be more generalized. Words are simply comma-delimited strings now, and have no duration, velocity, or time data. To create full sets of note, velocity, time, and duration data, all one has to do is combine four words.
The key component that I want to emphasize in development is the interoperability of the algorithms. For example, the XenCut/generalized fractal engine could be used to create random words for the new grammar engine's dictionary. A Lindenmayer system could then be used to string words together into phrases, and a stochastic engine could control the distribution of phrases.
I'm hoping that this development of easy-to-use algorithms will lead to the creation of the ultimate hybrid plugin that will bring together the strengths of all methods as I originally envisioned when I first began the program.
I've been working on airframe lately in hopes of getting the structure up to par with the other modules (progression module is my next target). I've come to the conclusion that generative modules need to be a lot smarter than they are right now, because they shouldn't rely too heavily on the structure module to provide "solid" structure data. Structures are really not very complex. To be perfectly honest, the best option would probably be a very simple KBS with a pre-programmed list of structure forms (ABABCB, etc). Until then, I'm overshooting the complexity. So the generative modules will be responsible for keeping the piece coherent and figuring out what to do if the structure modules sends overly-complicated (or overly-simplified) instructions.
The core system of airframe has been decided upon - at least for now. I'm proud to introduce it as the first mGen plugin to use a Lindenmayer system, also known as an L-system, which is basically a simple grammar system at first glance but has roots in fractals. I think the L-system will provide a refreshing dose of simplicity and organized complexity. I really won't know what to expect until I hear it, and if it works, it'll be far too good to be true given how easy an L-system is to implement.
Of course I plan on layering other processes over the L-system engine to refine the structure output (maybe an ear module?), so airframe will technically still be a hybrid plugin.
EvoSpeak is also still progressing.