WordSmith - Generalized Grammar

Today I began construction of a more generalized grammar framework - very similar to the one upon which GGrewve runs, except extended to work for melodic instruments as well as percussive ones.  I began a crucial part of this rewriting today with WordSmith - the new equivalent to GGrewveWriter.
WordSmith is a generalized grammar/dictionary synthesizer capable of taking a "training file" in MIDI form and constructing a dictionary from the file.  WordSmith, unlike GGrewveWriter, actually has a very flexible interface and of course will work for any instrument, not just drums.  In addition to the usual features of the last grammar analysis tool, WordSmith will also include extended features such as time compression and maybe even synthesis tools like hybridization and mutation for more random possibilities.
As a minor under-the-hood tweak, WordSmith will perform extensive quantitative abstract analysis on individual words (categorizing intensity and such) so that plugins like GGrewve don't have to waste valuable processing time doing analysis that can be done once up front instead of once every run.  This will also greatly increase the possibilites for such analysis, since a one-time processing cost will allow for much more extensive and in-depth analysis of the grammar. Users won't mind having to wait half a minute to create a dictionary, as long as it doesn't take the same amount of time every time the dictionary is used by a plugin.  Which it won't.  It'll only take milliseconds for the plugins to access that analysis data that will have already been created by WordSmith.
Grammatical subdivision is going full speed ahead, and I hope this promising method won't let me down.

Today I began construction of a more generalized grammar framework - very similar to the one upon which GGrewve runs, except extended to work for melodic instruments as well as percussive ones.  I began a crucial part of this rewriting today with WordSmith - the new equivalent to GGrewveWriter.

WordSmith is a generalized grammar/dictionary synthesizer capable of taking a "training file" in MIDI form and constructing a dictionary from the file.  WordSmith, unlike GGrewveWriter, actually has a very flexible interface and of course will work for any instrument, not just drums.  In addition to the usual features of the last grammar analysis tool, WordSmith will also include extended features such as time compression and maybe even synthesis tools like hybridization and mutation for more random possibilities.

As a minor under-the-hood tweak, WordSmith will perform extensive quantitative abstract analysis on individual words (categorizing intensity and such) so that plugins like GGrewve don't have to waste valuable processing time doing analysis that can be done once up front instead of once every run.  This will also greatly increase the possibilites for such analysis, since a one-time processing cost will allow for much more extensive and in-depth analysis of the grammar. Users won't mind having to wait half a minute to create a dictionary, as long as it doesn't take the same amount of time every time the dictionary is used by a plugin.  Which it won't.  It'll only take milliseconds for the plugins to access that analysis data that will have already been created by WordSmith.

Grammatical subdivision is going full speed ahead, and I hope this promising method won't let me down.

airframe

I'm working on a new structure module. Easy Contoured Structure worked fine for a while, but I've definitely outgrown it's capabilities and it's time for a completely new system. This new system will be called airframe, a name that embodies the simple, light, and flexible system that is to come.  I have yet to decide the actual algorithm type for airframe, at the moment I'm thinking a combination of KBS and grammar.
More to come on this.

I'm working on a new structure module. Easy Contoured Structure worked fine for a while, but I've definitely outgrown it's capabilities and it's time for a completely new system. This new system will be called airframe, a name that embodies the simple, light, and flexible system that is to come.  I have yet to decide the actual algorithm type for airframe, at the moment I'm thinking a combination of KBS and grammar.

More to come on this.

Swing Thing

It's another landmark day for mGen, as today was the first time a post-process module was ever used in the composition process. I made a very simple swing module called Swing Thing that offsets certain notes in the composition to give it a swing feel ranging from "very light swing" to "heavy swing."
The test run sounded great after I got the math down for the swing algorithm, which took a little trial-and-error. I was very impressed with the run time; mGen was showing the swing module as taking only 6% of the total composition time, even though the module had to loop through every single generative part and modify the timing of every single note that fell on a certain beat, which seems like a processor-intensive task. Nonetheless, Swing Thing chewed through the loops in no time.
A swing module was really the only immediate implementation that I could think of for post-processing modules, but it's already proven the power of post-processing to transform the entire composition. I'm sure there will be many more plugins to come.

It's another landmark day for mGen, as today was the first time a post-process module was ever used in the composition process. I made a very simple swing module called Swing Thing that offsets certain notes in the composition to give it a swing feel ranging from "very light swing" to "heavy swing."

The test run sounded great after I got the math down for the swing algorithm, which took a little trial-and-error. I was very impressed with the run time; mGen was showing the swing module as taking only 6% of the total composition time, even though the module had to loop through every single generative part and modify the timing of every single note that fell on a certain beat, which seems like a processor-intensive task. Nonetheless, Swing Thing chewed through the loops in no time.

A swing module was really the only immediate implementation that I could think of for post-processing modules, but it's already proven the power of post-processing to transform the entire composition. I'm sure there will be many more plugins to come.

Main Interface Upgrades

A good amount of progress was made on the main interface today.  First of all, I fixed the control drawing/resizing bug once and for all! It's very exciting because it was glaring flaw that I couldn't do anything about and it made mGen look a lot less professional because controls would draw incorrectly or in the wrong place.  All I had to do was change all the Gui, Move calls to Gui, MoveDraw! And voila!  The interface stays intact now regardless of how vigorously the user resizes it.  Beautiful.
I also filled the second modular panel of the main interface today with a "Run Time Breakdown," which basically keeps track of where the time is being spent during the generating process.  It displays an entry for the "render  time," which includes sorting the note data and converting to MIDI, as well as entries for the structure, progression, generative, and post-processing modules (coordination module yet to come).  So after mGen finishes a composition, it will show exactly what percent of the time it spent on each area, and color codes the entries appropriately so that resource hogs will show in less-friendly colors.  GGrewve, being the most cpu intensive plugin, takes up about 70% of the runtime in my current projects.
It's nice to be able to see where the time is being spent.  It's also nice to not have controls freaking out on my every time I want to maximize the window.

A good amount of progress was made on the main interface today.  First of all, I fixed the control drawing/resizing bug once and for all! It's very exciting because it was glaring flaw that I couldn't do anything about and it made mGen look a lot less professional because controls would draw incorrectly or in the wrong place.  All I had to do was change all the Gui, Move calls to Gui, MoveDraw! And voila!  The interface stays intact now regardless of how vigorously the user resizes it.  Beautiful.

I also filled the second modular panel of the main interface today with a "Run Time Breakdown," which basically keeps track of where the time is being spent during the generating process.  It displays an entry for the "render  time," which includes sorting the note data and converting to MIDI, as well as entries for the structure, progression, generative, and post-processing modules (coordination module yet to come).  So after mGen finishes a composition, it will show exactly what percent of the time it spent on each area, and color codes the entries appropriately so that resource hogs will show in less-friendly colors.  GGrewve, being the most cpu intensive plugin, takes up about 70% of the runtime in my current projects.

It's nice to be able to see where the time is being spent.  It's also nice to not have controls freaking out on my every time I want to maximize the window.

GGrewve Fill Dictionaries

Today was yet another huge leap forward for GGrewve.  I coded a second dictionary loading into the program so that it now keeps two dictionaries in memory: one for the main style, and one for fills.  Basically, a fill dictionary looks and functions exactly like a normal dictionary.  I wrote a small MIDI file that contained several nice fills and then passed it through GGrewveWriter, yielding a fill dictionary.  Along the way I had to do a lot of bugfixing on GGrewveWriter, which threw a fit because the fill patterns were a bit different from normal patterns.
At any rate, after everything was said and done, GGrewve was intelligently using a fill dictionary to make entrances as well as highlight fourth-measures.  The result?  Awesome.  Simply awesome.  It sounds great - it sounds real.  Even more impressive, GGrewve displays great inventiveness in using the fills.  As I explained the process of grammatical subdivision before, GGrewve basically chops up the MIDI files I give it and recombines them using intelligent analysis.  Not only were many of the fills very inventive (I wouldn't have thought to make them), they were coherent and well-placed!  I wasn't just hearing a repeat of the file I had fed into GGrewveWriter.  I was hearing an elaboration on those files - the same style, but not the same pattern.  GGrewve was not mimicking my speech, it was mimicking my ideas with its own speech (to use a linguistic metaphor).
GGrewve is by far my most impressive plugin so far, and with a solid drum plugin to depend on, I know it can only get better from here.

Today was yet another huge leap forward for GGrewve.  I coded a second dictionary loading into the program so that it now keeps two dictionaries in memory: one for the main style, and one for fills.  Basically, a fill dictionary looks and functions exactly like a normal dictionary.  I wrote a small MIDI file that contained several nice fills and then passed it through GGrewveWriter, yielding a fill dictionary.  Along the way I had to do a lot of bugfixing on GGrewveWriter, which threw a fit because the fill patterns were a bit different from normal patterns.

At any rate, after everything was said and done, GGrewve was intelligently using a fill dictionary to make entrances as well as highlight fourth-measures.  The result?  Awesome.  Simply awesome.  It sounds great - it sounds real.  Even more impressive, GGrewve displays great inventiveness in using the fills.  As I explained the process of grammatical subdivision before, GGrewve basically chops up the MIDI files I give it and recombines them using intelligent analysis.  Not only were many of the fills very inventive (I wouldn't have thought to make them), they were coherent and well-placed!  I wasn't just hearing a repeat of the file I had fed into GGrewveWriter.  I was hearing an elaboration on those files - the same style, but not the same pattern.  GGrewve was not mimicking my speech, it was mimicking my ideas with its own speech (to use a linguistic metaphor).

GGrewve is by far my most impressive plugin so far, and with a solid drum plugin to depend on, I know it can only get better from here.

Post-Processing Functionality

I began work today on implementing post-processing modules. The mGen now loads and keeps track of an unlimited number of post-processing modules and also stores and retains the configuration data, just like generative modules.

The only part left to do is handle the actual generation, in which mGen will have to pass the entire compositional data structure to the post-processing modules and update the structure based on the output of the modules.

Unlike the generative modules, which have permission to view the entire data structure, but can only to add note data to their respective channels, post-processing modules will be granted complete read and write access to the entire set of data to maximize the flexibility of these special modules.

Structural Updates & Touch-Ups

Several fixes and minor changes are going on in the mainframe. Loading and saving have each been completely reworked to use the GDS data system instead of INI file storage. The result is a smaller file that is easier to work with. The plugin loading algorithm has also been tweaked to no longer function on absolute paths but rather on relative ones. Now I won't have problems loading the project files I saved on my laptop into my desktop's mGen (previously the project files were not transferrable because of the differences in the file path names on my two systems, even though the differences are not at all relevent to mGen).

GGrewve Intelligent Decision Making

Major progress has been made with the GGrewve drum plugin. It now has the ability to determine which words are more intense based on an extremely scalable and versatile analysis engine. Using this knowledge, GGrewve is able to place words more appropriately than before. Without even needing to look at the context of the words in the original MIDI file from which they were extracted, GGrewve uses the words to simulate the way a real drummer plays. Accents and fills will occur more during even measures, with a greater weight every fourth measure. In this way, GGrewve allows listeners to more effectively keep track of the measure, which gives the composition a much greater overall coherency.

The intelligent GGrewve engine is a step forward in autonomous music generation!

GGrewveWriter Analysis Tool

The development of GGrewve is going well, but rather slowly. This is partly because of the difficulty in expanding the dictionary. This is not an unfamiliar problem: I ran into the same issues with Variating Drummer. It's generally difficult to write drum patterns in anything short of a full-blown sequencer. Since writing a sequencer is beyond my capabilities, I have developed a pretty cool alternative.

Enter GGrewveWriter, the intelligent drum pattern analysis tool that disects a drum beat and packages it up for use with GGrewve.

In a nutshell, GGrewveWriter takes a MIDI file that contains a drum beat, splits the beat up into sections of an appropriate length, and derives "words" from these small sections. GGrewveWriter pays close attention to the placement of words within the original beat and the subtleties of wordly interactions. GGrewveWriter then creates a compressed dictionary file that contains all the grammatical data about the drum beat found in the MIDI file. This compressed dictionary can be read directly by GGrewve, and is actually more efficient than the uncompressed dictionaries used previously.

The whole thing is very impressive in practice.

It took me no more than a few minutes to write eight measures of a neat little drum beat in a sequencer and export it to a MIDI file. After exporting, I let GGrewveWriter go to work with the file. After only a few seconds, I had a fresh compressed dictionary sitting in the folder. I loaded the dictionary into GGrewve and let the generation begin. Sure enough, out came forty measures (I had requested this much) of well-placed, humanized drum beat. I had actually made the original MIDI beat sound very stale (I did not vary the volume levels at ALL, so it sounded very robotic) to see how well the humanization routines within Grewve were working. Sure enough, the computer's output sounded a heck of a lot more human than the beat that I, a human, had created. The output was varied and clearly derived from my beat, but not exactly a copy and pleasantly unpredecatable.

Writing the beat, creating the dictionary, and generating took about seven minutes. Had I tried to achieve the same thing with the Variating Drummer, it would have taken hours and hours and the final result would not have been as impressive.

This is a very successful test for GGrewve, and I look forward to more impressive results in the future (we may finally be ready for drum fills!)

GDS Inspector

A few months ago, I developed a custom, flexible data structure designed to handle the challenges presented by the project in terms of data storage and transfer. I refer to these structures as GDS, or generic data structures. I have been improving on the capabilities of the GDS system since its inception. Among the many important features of the GDS is it's ability to store other GDSs within itself. A GDS may, this way, be nested up to ten times within another. In other words, you can have a data structure within a data structure within a data structure within a data structure, and so on, which is extremely handy for keeping data organized yet easy to transfer and work with at the same time. I can basically store an entire heirarchicaly organized pool of data in a single variable. Best of all, each GDS can be written and read from a file just as a single, large string would.

These structures, however, can get quite massive (especially the main structure that mGen uses to pass between modules - this structure usually has hundreds of sections and up to four nested levels).

Today I created a small tool called the "GDS Inspector" to facilitate the process of examining GDS blocks when debugging. The problem arose while working on GGrewve. I needed to inspect the dictionary block because I was having problems. Opening the block in notepad, however, was very messy because of the way GDS stores data (which is flexible and rather efficient, but not at all notepad-friendly). The program I wrote displays all the data in a given GDS block in a manner much more conducive to analysis - a treeview. A treeview is basically a hiearchy. One can see the nested levels of GDS storage and click on each entry to view the data held therein. This greatly facilitated the debugging process, not to mention I had a great deal of fun looking at how complex the main data structure actually is (notepad doesn't really do it justice).

So that's a nice little improvement in my working methods.