Generalized Algorithms: Source vs. Filter

Looking back on the creation and thorough usage of the XIAS algorithm library, it is clear that creating generalized algorithm engines provides a definite advantage to development, both in terms of time and content quality. Most XIAS algorithms, however, are similar in nature and unable to represent the entire compositional process.

In order to continue the success of generalized algorithm-building, I’d like to create a new library of algorithms, similar to XIAS, but consisting of a different category of algorithms: filter algorithms.

Upon inspection, it is clear that most XIAS engines have one thing in common: a chaotic, nondeterministic output. For these reasons, I have clumped them into a category of algorithms that I call “source.” Source algorithms, by my definition, take a simple input stream (for example, a time index) and convert it into a chaotic output stream. They are, effectively, “sources” of creative material for use in the process of composing. Of course, an ideal source algorithm generates output that, in some way or another, has a degree of coherence. For examples, the grammar engine draws coherence from repetition of small substructures, the Markov engine draws coherence from probability mappings, and the evolutionary engine draws coherence from the natural selection process. The simplest example of a source algorithm is a raw random function: rand(). Though it has no coherence, it fits the definition given above. This is an intuitive classification; programmers use the random function often as a “source” of chaos, so it is not difficult to see the logic classifying it as a source algorithm.

Filter algorithms, on the other hand, are deterministic and change the input stream in a predictable way. Filter algorithms have little representation in the XIAS library, though Fraccut partially qualifies due to some built-in features like automatic elimination of tri-tones. It is easy to think of a filter algorithm as a function of one or more variables that is called repeatedly on the input stream. A simple filter algorithm, for example, might take a pitch input stream and modify the stream to eliminate repeated pitches.

It is worth noting that both classes of algorithms may require an initial configuration that will affect the behavior of the algorithm – but this is not considered a direct input.

I see great potential in building a library of generalized filter algorithms. A source algorithm could be used to feed the input stream of a filter algorithm which, together, could essentially cover the entire composition process for a single part – from a creative source all the way to a constrained melody or harmony. Such intuitive flows of data have been integral to my past successes, and will no doubt contribute heavily to future ones.

Two Samples of Entropic Root

Today two samples showcasing multiple instances of Entropic Root have made their way to the samples page.  Unlike most other samples, these don't even require the assistance of ChillZone Pianist to provide supporting chords.  Rather, a single generative plugin does all the generative work for samples thirteen and fourteen.

Here's to a bright future for Entropic Root!

Entropic Root

After heavy development in ScratchPad, Entropic Root is now ready for full plugin status. As described in the previous post, Entropic Root uses a mathematical method to generate melodies. It extracts pitch and duration information from fractional power functions. The plugin also has several features that enhance variability and overall quality of the output.

Entropic Root, even in its infancy, is the most powerful generative melody plugin yet. A number of impressive compositions have already been written using only Entropic Root instances.

Several samples will be uploaded shortly.

Root Melody Method

With ScratchPad I've been rapidly working on new melody ideas.  One particularly interesting one revolves around raising numbers to fractional powers.  It's the first truly mathematical melody method that I've experimented with, and the results are turning out better than I would have expected.

The method of generating goes as follows.  First, the user chooses a fractional power that will be used to generate the melody as well as a digit depth that will be used in determining how far into the digits of the function the program should search.  The plugin then creates a base number by multiplying a seed by certain compositional indices such as the style class of the movement or the index of the chord rotation.  It then raises the base number to the chosen fractional power, removes the decimal point, and digs into the digits of the resultant irrational number until it reaches the digit specified by the depth setting.  This digit will be used to determine the pitch offset.

Such is only a fraction (get it?) of what actually happens during the generation - since duration must also be dealt with by similar means, and several other factors weigh in to improve the quality of the results.  Nonetheless, it's cool to think about "music drawn from the very nature of the square root function."

The plugin already beats all other melody plugins, hands-down.  Fraccut and Fraccut v2 were, of course, close contestants with the root method.  In the end, though, the ease of development in ScratchPad led the new module to victory.  The module is almost ready to bud off of ScratchPad and become an independent plugin.  I think I'll call it Entropic Root, since it both sounds cool and hints at the use of the "entropy" of fractional power functions (of which roots are a convenient class).

Below is an image of four instances of the plugin loaded into mGen.  The preview shows coherent, creative, and complex melodies:

SandBox: Lightning Fast Idea Development

Over the past week most of the work I've done has been in the SandBox with the multi-state analysis engine.  MSE is having mixed results with chord tension prediction and I may need to think about developing a more advanced mathematical engine to produce better results (for example, create large matrices describing relations and use algorithms to explicitly solve for partial relations rather than using weak value correlations).

The SandBox, on the other hand, is proving more valuable every minute.  Testing ideas is now easier than it's ever been before, and I've had less downtime over the past week than I can remember having in a long time.  I'm working on an extension of SandBox called ScratchPad that will further simplify the process of getting ideas into program form by allowing the user to employ a very simple, 4-part coding interface that automatically injects the four blocks of custom code into different areas of a predefined template, letting the template and ScratchPad do all the housekeeping work.

To put it in perspective, I just timed myself to see how long it would take to put a very, very simple idea into action.  I opened ScratchPad and made a simple Brownian motion generative module for melody.  It took about 55 seconds from opening a blank ScratchPad to having the code rendered and activated (set to the default running code) within the SandBox module.  I then opened mGen and tested the SandBox module just to make sure that what I had done worked - and indeed it did, a Brownian motion melody greeted the screen when the render finished.  Sure, it's not pretty, and it probably doesn't sound good.  Nonetheless, it demonstrates how ScratchPad and SandBox allow me to translate from ideas to code to music in almost no time at all.  There was certainly no wasted time.  ScratchPad whittles down the task of codewriting to make sure that the only thing the user has to write is code that is directly specific to the idea being implemented, not to other general tasks such as data handling, initializing, closing down, and all the other time-consuming tasks in between.

I have no doubt that there will be a great deal of ideas tried in the upcoming weeks with the help of SandBox and ScratchPad.

Multi-State Analysis Engine

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.

Curve Splicing

Using the SandBox, I've been developing some interesting ideas over past the few days. The most prominent is a novel technique I call "curve splicing." I've yet to see anything similar to it in the literature, so it could be a rather novel method. It's basically an intricate, formulaic method of melody generation.

Rather than use a single, complicated formula to generate a mathematical melody, this method relies on a system of simple formulae. A musical "idea" is represented by a system of curves. These curves needn't be complex. A system consisting of only basic linear functions and linear absolute value functions will suffice. Horizontal linear functions, however, should be classified separately from linear functions with a nonzero slope. Here's the trick: a "splicing string" is used to determine how to combine the curves to create the melody. The final output will essentially be a piecewise combination of the system's curves. The splicing string simply specifies which curve should be the active curve at any point in time (only one active curve at once...for now). Note that the splicing string can be generated from any valid string method...L-system, Markov, grammatical, etc.

Benefits of this method? Numerous. It has a relatively simple data structure, computing the curves is very simple so runtime is fast, and, best of all, the melodies (ideally) sound very structured because of the fundamental observation of contour.

Below is a diagram of the method. The splicing string isn't included, but this should illustrate the general idea:

Curve splicing is an exciting new melody method and I look forward to hearing it in action! I've already run some initial tests and things are looking promising. Perhaps the best part of all this is the possibility that I have created a truly novel method, considering that I have seen nothing like this in the literature. Cool!

The Sandbox

Though not exactly a plugin in and of itself, I'm working on a new module that will, if all goes well, enable rapid development of new ideas and new plugins like never before. The SandBox is exactly what it sounds like - it's a framework for playing with ideas. It's really just a very large and detailed template that is capable of switching between structure, progression, coordination, generative, and post-processing mode, so I can experiment with whatever type of module I choose. When SandBox is complete, it will have templates for every type of plugin designed to render the work of getting a new idea into music form as easy as possible. Without the hassle of having to set up a new plugin directory and rewrite the wrapping code for the module each time I have a new idea, I should be able to test way more concepts.

I'm hoping that the creation of the SandBox will mark a new phase in the development of mGen. I've always had a free-form development methodology, letting ideas come and go based on their applied effectiveness. Now, with the ability to see ideas in action with only a fraction of the development time, I hope to run through even more ideas in even less time - and have more of an applied focus than ever.

I'm already in the process of trying to decide which of my current ideas should be the first to play in the SandBox.

Pendulum

I ususally don't post things that diverge from the topic of algorithmic composition, but I can't help it this time.  I wrote and recorded a song last night dedicated to my AP Physics class (because that's how I like to spend my Friday nights!)

And so here you have it, a full-length song dedicated to one of my favorite apparatuses in physics: the pendulum.  Personally, I think this could become a hit.

All original work :)

[youtube=http://www.youtube.com/watch?v=DWsAieEpbVs]

Fraccut: Second Generation

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.