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.

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).

Module Instructions

After the recent data structure overhaul, adding new features to mGen feels like a breeze, which is a nice treat. Today I wrote a basic module instruction mechanism that allows the structure module to work with the generative modules to coordinate the composition at a higher level. This is, of course, essential to the coherence of the composition and is a feature that will require a lot of refining if I hope to get good material out of mGen.

Basically, the structure module can now coordinate, for instance, when the piano should come in, when the drums should make an entrance, when things should get softer, and when things should get heavier. There's now an overlaying set of general module instructions to help the generative modules achieve a greater coherence.

Also, the data structure now allows other modules to effectively "see" each other even before they have generated any output. This was necessary at first because the structure module needed to be able to see the generative modules before it could start giving part instructions...you can't rely on a nonexistent pianist to start a song, nor a nonexistent drummer to get fancy with a solo! As a consequence, modules can also now see each other. Conceivably, this could be used for a dynamic interactivity between them. Although there is no data structure in place yet to allow modules to communicate between each other, that may be a feature in the future. This could allow, for example, the drum and the bass modules to "establish a groove" before they start generative the composition. Communication is essential in a real band, so it should be essential in mGen as well.

Lots of progress is being made these past few days. mGen's compositions are taking less and less of my intervention to sound good. I usually just plop in a synth doing some rhythm work or harmony and then lay down a drum groove. Throw in some nice mixer effects and it all sounds pretty darn impressive, or at least I think. Soon enough mGen will be doing all of that autonomously. It's a scary thought. But it's the future of music.

Complete Internal Overhaul

Tonight was a long night for mGen. At the begin of the night, the poor thing was told it had an obsolete internal data structure that lacked much structure to speak of. Furthermore, mGen was accused of inefficient data handling that was making other modules work harder than necessary.

After an immense surgery that lasted about four hours, mGen is now smiling with a brand-new, sparkly internal data structure. The structure now conforms to the data structures used by other modules and makes it much easier for all other components of the program to access information about the composition on the fly. The surgery has, however, rendered mGen uncompatible with most of the previous plugins I wrote to accompany it. They too much schedule an appointment for surgery to become capable of taking advantage of mGen's new data structure.

In short, I rebuilt the internals of the mGen framework from scratch. It's an investment in the future, where data handling will be done much more efficiently by the program. It's really quite a huge change/improvement, as reflected by the half a thousand line increase in code length.

mGen Sample 2

Believe it or not, the program has undergone many changes since the last sample. I created a brand new structure plugin based around the idea of a smooth, contoured intensity structure. I also injected a few lines into most of the other plugins to give them a primitive obey-the-structure rule. Most of the instruments now actually pay attention when the structure module tells them to play loud versus when to play soft. Some, however, still don't have this capability, and most lack any real sense of volume other than the most basic loud and soft abilities.

Still, these improvements constitute serious advancements in mGen. I find this sample to be moderately pleasing. Although it gets repetitive in some places, I'm very pleased with the dynamics. I'm aware that they are still laughably lacking, but at least there ARE dynamics in this sample, unlike the last.

And yes, I know that it sounds very similar. That's due to the lack of rendering options that I have given the program to this point. I'm more concerned with the scoring than the rendering at the moment, but I'll get around to expanding the instrument catalog eventually.

Oh, and a little side note - the drum "solo" at the end was actually a very unintentional and very strange glitch. I've no idea why the drums played a whole extra measure...I'm still trying to figure it out. Three months in and the program already has a mind of its own - I guess I should be proud and worried at the same time!

mGen Sample 1

Well, here it is (the clip should be playing when you load the blog).

Eighty-nine hundred lines worth of code, embodied in a single audio clip. Yes, I know it's bad, probably pretty much intolerable by the standards of any of you guys. So am I wasting my time? Thousands of lines and all you get is an overly simplistic, predictable drum beat and uninspiring arpeggiations layered on top of overly simplistic chord progressions? No, not at all. Most of the coding so far has been dedicated to creating the framework for mGen, not the actual generative modules. The real work so far was getting a progression, getting arpeggiations, getting a drum beat, and pulling them all together into the same mp3 file and rendering them all automatically (everything in this sample was done automatically, I was literally one button click away from my rendered mp3 file).

I'd say I'm pretty much on target for my goal. For starters I've already achieved the one-click philosophy cited in my proposal. My system has now effectively demonstrated its ability to go from nothing to a finished mp3 file in only a single button click. Also, when one considers briefly the complexity of computer music, the fact that mGen's first sample sounds even remotely close to rhythmically and harmonically sound is quite an impressive feat. There are no chords that sound bad, most of the progressions actually sound good. The arpeggiations sound relatively good too. Both of those items were non-deterministic, meaning mGen completely determined each chord in the progression and each note in the arpeggios (actually it also individually determined the notes in each chord of the progression).

So, in defense of my somewhat-lacking first sample, I have clearly shown that what I am wanting to do is possible. I have not spend too much time coding the actual generative part of my program, so I didn't expect a diamond on my first try. I poured in a lot of effort, and I think I reaped a fair reward.

From here, onward to better-sounding samples.