No, seriously...this is by far the most epic - and by epic, I mean legendary, incredible, amazing - failure I've ever had. Don't ask me how or why, but, for some reason, changing the size of my diffuse texture to 1x1 caused...no, not a scene of solid-colored objects as I had hoped...no, not a failure message from D3D...no, not a crash...but rather, a mind-blowing scene of recursion. Of course, it should have been obvious to me that resizing a diffuse texture would...cause it to be replaced by the primary render target!?!?
This is by far the coolest glitch that has ever befallen me. Every surface displays an exact replica of that which is rendered on the screen (and it also happens that I had SSAO and DoF turned on at the time of the glitch...so it's a rather beautiful setting for a glitch!). Good example of recursion, yes? Also quite a trip.
But seriously...why didn't I ever think to do this intentionally???
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.
Finally, I found the culprit causing Fraccut's random behavior. Indeed, one tiny call to a pseudorandom generator got passed my eye and was causing the entire process to change over the composition. Now Fraccut's ideas are static, as expected.
Why, one might ask, would I want the ideas to be static when the so-called "glitch" was allowing them to be dynamic? Well, in time I will make them dynamic. But I want the variation process to be controlled so that Fraccut's ideas evolve and mature over time like those of a real musician. Idea development, while in the end must be unpredictable, shouldn't be left to a totally random process that has no concept of development. I will start working on algorithms that slightly variate the seed input of the cutting engine, which should produce modified ideas that resemble the original ones.
With the engine glitches a thing of the past, I can really start concentrating on allowing Fraccut to fulfill its potential.
I'm working on giving Fraccut a greater sense of continuity. What I'm really trying to do is expand Fraccut's attention span, so to speak. Rather than making large jumps back to parent blocks when chord changes and such occur, Fraccut should have the ability to continue on with a previous idea provided that the idea meshes with the new key. This is the fifth major controllable variable added to the configuration interface and it will, with any luck, really separate the melodies from other static modules or other Fraccut modules with low continuity settings.
On the other hand, I'm still trying to figure out how on earth Fraccut is continuing to generate new, dynamic ideas when I'm restricting it to only one idea per composition at the moment. I'm having trouble with the randomness engine. It's really a very strange thing. There should be, at present, no way for randomness to enter the cutting process. The process is controlled completely by a string that is generated before the cutting is done. However, Fraccut's output is not static over measures, as one would expect it to be with this system in place and holding the input string constant. The plugin really does have a mind of its own at the moment. While it's cool that Fraccut is breaking my rules and running with its own ideas, I must ensure that the engine is operating exactly as I expect it to before continuing development of more advanced features. I need precise control over Fraccut's ideas so that I can distribute them properly through compositions.
Overall, however, the fractal experience continues to be a very rewarding one. I am hearing many original, coherent compositions that are only a few steps away from comparability with human compositions.
Alas, it seems that much of the creativity recently attributed to the two excellent performances of Fraccut may be the result of glitches rather than a well-written algorithm. More stress-testing of Fraccut has revealed some motifs that actually appear in numerous compositions, indicating a problem with the code (since the engine isn't supposed to inherently "like" anything).
New creativity methods have been implemented. I'm still using the pseudo-random generator approach, but in a different, more coherent way.
Fraccut is turning out to have many strange glitches nested within the engine. Strange durations and odd beat patterns are starting to emerge. It looks like the process of refining fractal cutting won't be as easy as it first appeared. But then again, that would have been all too easy.
The hardest part of the whole process will be developing helpful debugging tools. I'm going to have to design some interfaces to let me really see what Fraccut is thinking in a visual way so I can explore these strange glitches that are apparently more than just typos in the code.
I hope that, when Fraccut comes out clean, it will still sound as good as it did the first two times.
Several updates tonight. First of all, I got the new structure module Manual working. It'll be the structural equivalent of ProgLib - a simple library of structure choice in formats like ABABCBA, etc. I'm also experimenting with a new way of grouping instruments for issuing part instructions. As simple as the plugin is right now, I can't tell if it's actually doing anything. It more or less provide uniform movements with nothing going on, which is fine with me while I test the other modules. I guess that's all I really need for a while - a solid foundation.
I uncovered several problems in ProgLib that were keeping it from randomizing the progression properly. I also added a new library called "Typical," which will include the most basic progressions found in practically everything.
Output started sounding decent again but wasn't anything special. EvoSpeak's looping is getting kind of annoying, I need to make it dynamic as soon as possible. On the upside, I still have almost no complaints about GGrewve. I often forget that I actually have had great success on a at least one plugin. GGrewve does its job so well that I forget it even exists; I assume the drum tracks just happened magically.
Towards the end of the night a glitch in ProgLib actually contributed to a very nice assisted composition. I've started documenting interesting glitches now because the products can be quite awesome. In this glitch, ProgLib was failing to read one of the new progressions in the "Typical" library properly. It had the chords right and it had the durations right, but the fact that one duration was twice as long as the others caused something to go wrong internally (probably a duration counter), causing ProgLib to write a pleasing 5/4 progression that cycled. In other words, ProgLib would add an extra measure each cycle by doubling one of the single-measure duration chords. Very strange indeed, but it resulted in an inspiring composition.
There's nothing better than joy in things going wrong.