CrystalNet: Looks Promising

CrystalNet is now up and working.  Though only in an alpha stage with very few features and no configuration front end, the CrystalNet engine is already providing good results.

I've only run through a few compositions with the new structure module, but already I can appreciate the diversity of structure that Manual didn't offer and the coherence that Easy Contoured Structure couldn't provide.  It looks like continued development of CrystalNet will provide another valuable plugin for mGen.

Here's a sample screenshot illustrating a fractal structure:

On another positive note, I had the pleasure of listening to a jaw-dropping composition tonight made by CrystalNet and an assortment of randomly-configured Fraccut plugins.  The sample definitely warrants an upload.  It's not altogether good until the strings come in behind the oboe.  But it's when the accompanying oboe comes in that the composition attains about twenty seconds of bliss.  The dual oboe harmony is beautiful.

Once again, mGen has reminded me why I pour my life into algorithmic composition.  Once again, I feel completely and totally fulfilled.

CrystalNet: Early Tests

With XenCut fully-working, preliminary CrystalNet tests began tonight.  The testing was really just limited to observing how the XenCut engine operates under the parameters required to generate a structure.  The parameters differ greatly from those used to generate fractal melodies, since the concept of abstracting a structure to a fractal pattern is completely different than abstracting a melody to a fractal pattern.  In particular, the engine had to work with blocks of much smaller size (a single unit represented an entire movement of the composition) and deal with the fact that the starting material consisted of a few very large blocks placed at the root block.

Judging from a graphical display of the results of the cutting, CrystalNet (and XenCut) already seems to be doing a good job of handling the structure.  The results were similar to the diagrams I posted a while back that came with the original "random cutting structure module" idea.

My only concern is the depth of this abstraction.  Taking a composition, splitting it into pieces, then treating each instrument's instructions like physical block in space certainly doesn't seem as intuitive as treating the individual notes of a melody as blocks.  Though the output looks nice on screen, it may result in incoherence and seemingly-random part instructions.

I really won't know how well the method fractal/random cutting works for structures until CrystalNet is up and generating compositions.  If all goes well, that should only take another week or so.

XenCut Engine

As I mentioned earlier, a new fractal/random cutting engine is under development.  The goal of the new engine is to be quicker and easier to implement, more flexible, and more powerful than the Fraccut engine (the original cutting engine).  This new engine will be called XenCut.

XenCut went through some preliminary tests tonight and is already performing well.  Since it's based on the OS data framework, the code looks very readable and runs fast.  But the real power of the engine is in the new cutting methods.  The engine now has three cutting "modes": linear factor, divisor, and offset.  The linear factor simply takes the cutting parameters to be coefficients (multipliers) of the original block widths.  The divisor mode does the same but with the reciprocal of the parameters (i.e. division).  Finally, the last mode, which is already coming in very handy for CrystalNet, simply takes the parameters to be offsets (constant factors).  The third mode helps to avoid strange durations and still find valid cuts when the original block widths don't fall within the typical power-of-two ranges.

I expect XenCut to find application in many more modules, and I hope it will provide a valuable source of fractal building blocks for future modules.  CrystalNet will be the first module to make use of the XenCut engine.  Given that I've found no other adequate way to do random structures, XenCut will really prove itself if it can power a working structure generator - that is, if CrystalNet comes through.

Crystal Network

Introducing a new structure plugin: Crystal Network.  Although it has absolutely nothing to do with crystals, this plugin will be based off of a freshly-rewritten fractal cutting engine similar to that of Fraccut.  The engine is undergoing a total rewrite using some different techniques as well as the OS data structure instead of GDS.  The new engine should be more robust and easier to handle than the Fraccut engine.

If fractal cutting works half as well with structures as it does with generative modules, mGen will be cranking out even more fantastic pieces in no time.

For it is Better to be Simpler

Though Fraccut only has a very basic variation system right now, it's enough to almost ruin the coherence that, during the early stages, sounded so promising. But there are plenty of ways to fix that. Repetition of ideas has been almost totally destroyed, especially when multiple Fraccut parts come together. There are several problems with the method of generation right now:

  • Each variation is pseudorandom, so there exists an infinite number of "permutations" of the idea. Does this not completely defeat the purpose of the seeding engine?
  • Other than the single "styleclass" parameter that the generative modules get each movement, there is essentially no way of coordinating ideas across multiple modules. The lack of coordination module functionality is starting to bring everything else down. This avoidance won't be able to go on much longer, as it's quickly becoming the system's bottleneck.
  • Variation is based on seeds right now...maybe it would be smarter to base variation on a separate variation engine? Perhaps some kind of sub-module that could be used across multiple generative modules and offers a variety of variation algorithms? Sounds like it'd be worth a try.
  • Variation is performed on both seed strings. It would probably be more coherent to only perform variation on the offset string. I'll see to this once the new fractal cutting engine is in place.

On the side, the new cutting engine (still without a name) is coming along nicely. The OS data structure is performing well and code readability is better than ever.

It'll be exciting to see how the fractal structure module will perform in comparison to Manual and Easy Contoured Structure.

Fraccut: Equality Malfunction

Alas, Fraccut has purported to offer equality to its block slices, but has done so falsely until now. The equality parameter, as I just discovered, is completely broken. No wonder I haven't heard any lovely arpeggiations from Fraccut. I set the equality to 100% and the slices are still rhythmically as normal as a tangent graph. Which isn't good.

A long night of bug-hunting awaits.

Object System: New Data Structure

A new data structure was conceived today. While GDS is very powerful, it's not very efficient, and code readability can become an issue when several structures are nested. It's difficult to retrieve multiple-nested variables because that requires first retrieving the nested structures sequentially, which can get annoying.

Object System, to be abbreviated OS, is designed to be a speedy and easy-to-use alternative to GDS. Syntax for OS is as follows:
// Initializing an OS structure and writing some variables
OS("myvar1=value!",OSstruct)
OS("myvar2=another value!",OSstruct)
OS("myvar3=a third value!",OSstruct)
OS("myvar1.substruct.nestedvar=a nested value!",OSstruct)

// Reading a variable
OS("myvar1.substruct.nestedvar",OSstruct)

As one can see, the syntax is very concise and designed to offer maximum code readability with minimum wasted coding time. Also, nested variables are as easy as using the typical object-oriented dot operator. Of course it isn't true "nesting," like GDS, but it still offers good readability.

Finally, the performance benefits of OS were measured against GDS to make sure that OS is more efficient. Though the graphs don't display much gain, the performance tests did NOT measure the access times on nested variables, which would have taken GDS MUCH longer to retrieve and OS would have pulled ahead significantly.

A graph of performance follows

I hope to redesign the fractal cutting engine soon with the help of OS.

Implementing a Fractal Structure Module

The diagrams given in the last post would seem to imply that making a structure module out of a fractal cutting engine would be easy. The truth is, however, that it's nowhere near as straightforward as making a melody.

Some of the central problems I'm trying to resolve at the moment:

  1. What blocks do you start with? Would slapping a bunch of root blocks that span the whole composition at a time offset of zero produce as good of results as a more sophisticated method? Or does the cutting engine bring equal complexity out of both of these situations?
  2. How do you handle separate pieces/parts/movements (whatever you want to call the compositional "divisions")? It's not hard to conceptually see that the blocks need to span more than one movement in order to be interesting (otherwise what would make this method any different from random selection?), but how does one know where to create a division? What about the fact that blocks will inevitably overlap divisions? The data structure does not allow multiple part instructions per movement for the same generative module, so instructions must not overlap.
  3. Once and for all - how should cutting work? Should it be based on divisors or on linear multiplicative factors? Furthermore, should we allow the engine to invert the durations of the old and new block so that the cut includes its "complementary" cut (i.e. the same cut in the reverse order)?

And finally, there's still the question of tempo, time signature, and pretty much all other things dealing with time that needs to be addressed. The relationship between the structure module and the coordination module still needs to be determined, and the structure module needs to become more influential over the others. After all, it crafts the entire composition. It should do more than say "start" and "stop."

Obviously there's a lot of work left to do with the core modules. Given the recent progress in generative modules, however, it's not surprising that the other modules are starting to look weak. That's the way it works with this project. A breakthrough in one thing causes everything else to look inadequate. Slowly but surely, the quality of each individual part rises to meet the expectations of the leading components.

Fraccut: Variation Using Seed Strings

Work has begun on the Fraccut variation algorithms.  The real question is how to control when the seed strings should be variated.  Should a simple modification be made every measure?  Should these modifications be saved so that all 2nd measures, for example, should be identical?  What ensures that a modification will make musical?

It's difficult to answer these questions since the variation engine, unlike most implemented before, is decidedly nonlinear.  Due to the nature of the pseudorandom generator, a tiny change in the seed string could completely alter the musical "idea."  This being said, how does one ensure some kind of regularity in the musical ideas expressed by such a pseudorandom seed-string system?

All these questions must be tackled before Fraccut will come to completion.