Posts In: XIAS

Multi-State Analysis Engine

December 14, 2009

Yet another generalized algorithmic engine has been added to the XIAS library. Multi-state analysis (abbreviated MSE for "multi-state engine") is way of describing the intrinsic "value" of certain state combinations based on the partial analysis of relationships between individual states. The engine is, more or less, a creative implementation of an inference algorithm. But here's the best part - the engine takes categorical states as an input and transforms them into an arbitrary quantitative measurement.

It's easier to explain how the algorithm works in practice. Suppose the user wishes for the machine to know that eating ice-cream on a warm school day is "good." In particular, it's better than eating ice-cream on a cold school day. Still, a non-school day is better than either of these situations, regardless of temperature and presence of ice-cream. The following statements might be made to the engine:

```mse_SetStateValue("icecream,warm,schoolday",10) mse_SetStateValue("icecream,cold,schoolday",5) mse_SetStateValue("icecream,warm,!schoolday",50) mse_SetStateValue("no_icecream,cold,!schoolday",45)```

From these statements, we might ask the engine to infer the intrinsic "value" of ice-cream, the weather, or a school day vs. a non-school day. More interestingly, we might ask the engine to infer the value of the situation in which we have no ice-cream, but it is a warm non-school day ("no_icecream,warm,!schoolday). The second inference would be much more interesting, because the engine would base its response on not just the sum of predicted individual state values, but also the predicted values of the partial relationships between the states (no_icecream to warm, warm to !schoolday, and no_icecream to !schoolday). Notice that we can use any syntax for the categorical inputs - the engine is not concerned with symbols such as ! and _, it treats each state uniquely. The names of states are for user convenience only (and a great convenience it is to have this flexibility!)

For this particular situation, the ability to analyze first- and second-order relationships between states doesn't contribute much to the quality of the overall analysis. However, thinking of this engine as applicable to an analysis of music, it is easy to see how useful the ability to analyze n-th order relationships would be. What is the contribution to tension of a seventh chord being played on the third beat of the measure? How pleasing is it to have [y] follow [x] in a melody given that the root is [z]? These kinds of questions are difficult to answer without highly-specialized analysis engines. But the XIAS MSE can do just that - place quantitative values on multiple-state situations based on partial relationships between the states inferred from given situational values.

I am already in the process of evaluating the abilities of the multi-state analysis engine in predicting the tension of chords based on individual note offsets. With any luck, MSE will prove to be a valuable addition to XIAS.

Fraccut: Second Generation

December 2, 2009

After a very successful life, Fraccut has finally received a full upgrade to version 2. The key difference in the second generation Fraccut plugin lies in the implementation of the random cutting engine. While the first version used a custom random cutting engine (the first I ever wrote), the second version exploits the simplicity and power of the XIAS generalized random cutting engine.

The XIAS engine has already helped eliminate some of the strange artifacts present in Fraccut melodies generated with the old engine. The old cutting method had a few flaws that I identified as contributing to a non-uniform distribution of rhythmic and tonal patterns (that is, certain patterns occurred far more frequently than others). There was, in fact, a single rhythmic pattern that kept appearing in almost every Fraccut melody. Perhaps an observant listener will be able to discern this repeated pattern from the samples. This repetition was starting to wear on my nerves, considering the fact that I had not intended for Fraccut to maintain any stylistic coherence across multiple executions. Regardless, the new cutting modes available in the XIAS engine eliminated this strange repetition.

The increased compositional ability of Fraccut v2 has already been observed in several pieces. I am uploading Sample 12 at this very moment to showcase the new incarnation of a great plugin.

ChromoRhythm

November 26, 2009

ChromoRhythm is a new generative drum module that combines many of the recent ideas I've had surrounding percussive generation.  One of the main features of ChromoRhythm will be the genetic (chromosome-based) configuration storage system, which will facilitate some degree of dynamic mutation of the drum styles.  Though I have yet to decide how the evolutionary fitness function will be implemented and whether it will be subjective or objective, I believe that the ability to convert information between chromosome-like data structures and configuration variables will enable a degree of variability unknown to previous drum modules.

Naturally, ChromoRhythm will be measured against GGrewve, since GGrewve is the current standard in drum pattern generation (and an excellent standard, at that).  Though I doubt that ChromoRhythm will ever be able to surpass GGrewve in human-feeling beats, the new data paradigm employed by the engine should allow it to trump GGrewve in terms of dynamic playing and variability of style.

Many of the details of Chromo are still being worked out.  Here are a few things that are already coded or conceptually established:

• DNA data structure consists of a long string of numbers
• Internal function converts between DNA strings (for use with the generalized XIAS evolutionary engine) and global configuration variable states
• Engine uses a "base style" for each individual drum, as specified by the DNA
• Engine layers "variations" on top of the base style for each individual drum, as specified by the DNA
• Engine adjusts playing dynamics based on movement intensity as well as coordination accenting instructions; DNA specifies the degree and exact parameters of the dynamics

One of the main questions upon which the development of ChromoRhythm is hinging concerns the fitness function.  I see two ways of doing it:

Objective Fitness Function - ChromoRhythm takes a drummer, randomly mutates the DNA of the drummer, then runs a fitness function on the mutations.  The fitness function is the first-ever "ear module" employed in the development of mGen, and mimics a user that listens to the beat.  The fitness function assigns points based on how well the drummer lines up with the coordination instructions, how effectively the dynamics change the style, and how pleasing the beat is in general.  The XIAS evolutionary engine then evolves the drummer mutations to the next generation and repeats the process for a set number of generations (or, alternatively, until the population reaches a specified mean fitness value).

Subjective Fitness Function - ChromoRhythm creates a pool of potential drummers to begin with.  The user selects an option in the interface that makes Chromo generate a channel for each potential drummer during the composition of a single piece.  The user then listens to the piece, muting all but one channel, and assigning points to the drummers based on how much he or she likes the style.  The XIAS evolutionary engine then evolves the drummer pool, as detailed above.

One may see that these two methods have very little in common - in fact, the first details a method of evolving substyles of a single drummer configuration, while the second involves evolving overarching drummer configurations.  Perhaps, then, both of these methods can be combined.

Needless to say, the logistics of implementing a genetic algorithm aren't at all simple.  Conceptualizing the process takes far longer than actually implementing it.  Determining what exactly should be evolved, how populations should be treated, which individual should be played, and how fitness points should be assigned will all heavily affect the output of ChromoRhythm.

Generalized Markov Engine

November 16, 2009

Picking XIAS up again, I'm now working on developing a flexible and lightweight Markov engine to give the XIAS library stochastic abilities.

Potential features for the Markov engine:

• Hierarchical storing of event probabilities for fast access time
• Will require hefty upgrade of Object System data structure
• Similar to GDS
• Improve access times for complex data structures
• Overlapping of orders
• Markov chains of different orders can have different "weights" that contribute to the overall probability of an event occurring
• Gives the user the ability to control how deeply the engine considers the past states when calculating probabilities
• Arbitrary event-handling
• Events don't have to take any particular structure - in fact, events could even have other data encoded into them to further enhance the predictive capabilities of the engine when outside variables may be influencing the future

Unfortunately, as mentioned in the notes above, making the engine efficient is going to require an overhaul of the Object System data structure created recently. It will require the ability to store substructures as single elements of larger structures to speed up access times (which I'm quite certain would get out of hand quickly for large systems in which many events contribute to the weightings). This ability will bring OS closer to the functionality of GDS. The main difference, however, will lie in the syntax. I still intend for OS to have easy, OOP-like syntax (Parent.sublevel1.sublevel2 ... variable = blah). All previous OS code will need to function after the rewrite.

When the Markov engine is finished, XIAS will boast a truly wide range of algorithms. I can only imagine the hybrid possibilities.

Here's what I'm thinking: a genetic algorithm that dynamically evolves Markov probability spaces that are based on an underlying grammatical system analysis, wherein the words of the grammar come from a fractal cutting engine whose parameters are fed by an L-system. Talk about one hybrid algorithm to rule them all!

Spirit

November 13, 2009

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

Genetic Algorithm Performance Testing

October 25, 2009

Having laid down the foundations of the XIAS genetic algorithm engine, I decided a performance test would be necessary to get the most out of the engine. Genetic algorithms, unlike most of the other methods that I've explored, are highly impacted by small quantitative tweaks to the engine, so performance can be gained by extensive testing of parameters.

Some preliminary tests were run tonight to determine the most effective mutation rate as well as the best mutation mode. I developed two mutation modes for the engine: Mode 1 allows an allele to mutate to any other allele that has been specified as part of the allele set of the engine. Mode 2 allows an allele to mutate only to an allele that already exists on the individual. In order to test these modes, the engine ran through 1000 genetic algorithm populations, keeping track of how many sub-loops it took to optimize the population each time. Each population was allowed a maximum of 100 loops to become perfectly optimized. Obviously, the idea is for the populations to optimize before those 100 loops are up.  The population optimization times are then averaged across the 1000 populations in order to achieve more accurate results.  Note that lower numbers on the graph are better (because the population optimized faster).

A couple of notes about the engine that stem from the graph:

• Mutation mode 1, in general, optimizes faster than mutation mode 2
• Mutation mode 1 is most efficient with a mutation rate of around 4.5% to 5.5%
• Mutation mode 2 is most efficient with a mutation rate of around 6% to 7%
• Mutation mode 1 provides more consistent optimization (notice that mode 2's curve changes directions several times, whereas mode 1's curve changes direction only once, at the minimum)
• The optimization time of each mode can be roughly approximated by a cubic curve

Notes on Implementing Genetic Algorithms

October 18, 2009

XIAS (cross-integrated algorithm system) supports the following algorithm types so far:

• Fractal
• Grammar
• L-System

The next natural extension of XIAS is an implementation of genetic algorithms.  I have a bit of experience with genetic algorithms from designing the EvoSpeak engine, which basically combined stochastics and genetic algorithms to evolve towards good-sounding melodies.

In keeping with the overall theme of the XIAS project, the designs for this genetic algorithm implementation focus on portability and ease-of-use.  As such, the system may seem a little oversimplified.  Only time will tell whether it will suffice for algorithmic composition needs or whether I will need to extend the features of the genetic algorithms.  For now, here are some notes that I've brainstormed for the implementation of this new system.

Data Structure of the GA Engine

• Engine
• Alleles (effectively the algorithm's domain; string)
• Cumulative point distribution (count; integer)
• Individuals
• Data String (genetic data; string)
• Points (count; integer)

GA Engine Operation

• Create m individuals with random alleles
• Rate each of the individuals
• Pass data string to transform function
• Feed transformed output to fitness evaluation function
• Distribute points according to fitness performance
• Breed the top n individuals according to point distribution with each other to create m new individuals
• Repeat with the new generation of individuals

Mutation in the GA Engine

• Deterministic Approach
• Create a function that takes two parent alleles and returns a third allele different from both (think cross product)
• Run the function on every qth allele
• Nondeterministic Approach
• Replace a child allele with a random allele with a given frequency

Quick Summary of GA Engine Implementation

• Randomize Individuals
• Rate
• Functional Transformation
• Fitness Evaluation
• Point Allocation
• Reproduce
• Allele Combination
• Allele Mutation
• Repeat

The only real problem left to solve is concerning reproduction.  How do we choose which individuals to combine with which individuals in order to produce a population of exactly m members, given that we want the children to have the best possible combinations of genes based on the point distribution of the parents?

ChillZone Pianist v2

October 15, 2009

ChillZone Pianist is finally getting the update it deserves.  The first of many style options, left hand arpeggiation, is tentatively working.  The plugin takes advantage of the new generalized algorithm include file (code-named XIAS).  In particular, it uses a Lindenmayer system to control an underlying grammatical engine.  The words are generated randomly using Brownian fractal motion.  The results sound great for preliminary runs.  Though some of the arpeggiations the program comes up with aren't too compelling, most of the output sounds good and is both coherent and creative.

After some more initial testing, I'll implement an array of new styles so that ChillZone Pianist will finally be a flexible piano plugin.  I intend to flesh out the options for chord, rhythmic chord, melody, and abstract, as well as arpeggiation.