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.