- Wrote libraries to handle more specific music functions and data structures, including
- Fractal Spaces
- Fractal Blocks
- Learned more LISP
- First MIDI output from LISP (very basic random patterns)
I think I'm headed down the fractal cutting road. After all, Fraccut has served me well for many, many compositions, so why not reuse these techniques in the new LISP library?
Finally, having completed a basic implementation of Contour Grammar, I am getting to see what the idea sounds like in musical form. Indeed, some very interesting effects have been achieved thanks to the functional phrase language as well as the use of coherent random sources (which I will discuss at some point in another post). However, even this idea is lacking the coherence of Fraccut, and it bothers me enormously that such an elaborate idea as Contour Grammar can't even beat a relatively simple implementation of random fractal cutting, a rudimentary mathematical process.
Of course, it's very obvious why Fraccut still holds the record for best melodies. Since the cutting engine essentially starts with the chord progression as a seed, coherence is almost guaranteed. It's a powerful effect. Yet, the reality is that Fraccut is hardly aware of what it is doing. In a sense, the coherence generated by Fraccut is nothing more than a cheap trick stemming from the clever picking of the seed. Nonetheless, it undeniably works better than anything else. In the end, I am concerned only with the audible quality of the results, not with the route taken to achieve said results.
That being said, the big question now is: how can Contour Grammar pay closer attention to context in order to achieve greater contextual coherence? It would be nice to somehow combine the internal consistency of Contour Grammar with the external, contextual coherence of Fraccut.
Grammatical fractal cutting, anyone?
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.
In keeping with the spirit of the recent drive to create a "generalized" algorithm system (starting with the XenCut fractal cutting engine mentioned a while ago), I'm beginning yet another grammar engine. The goal this time? Lighter and more portable than WordEngine. Easy applicability, easy conversions between words and soft patterns of notes, etc. The engine will also be more generalized. Words are simply comma-delimited strings now, and have no duration, velocity, or time data. To create full sets of note, velocity, time, and duration data, all one has to do is combine four words.
The key component that I want to emphasize in development is the interoperability of the algorithms. For example, the XenCut/generalized fractal engine could be used to create random words for the new grammar engine's dictionary. A Lindenmayer system could then be used to string words together into phrases, and a stochastic engine could control the distribution of phrases.
I'm hoping that this development of easy-to-use algorithms will lead to the creation of the ultimate hybrid plugin that will bring together the strengths of all methods as I originally envisioned when I first began the program.
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.
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.
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.
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:
- 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?
- 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.
- 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.
MGen is in great need of an algorithmic structure module with some degree of order. Fraccut has enjoyed such great success in the area of melody generation; I figure it can't hurt to try applying the fractal cutting engine to structure modules.
The good news is that it won't be hard to beat a manual structure. The ideas attached below seem pretty promising.
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.