I'm not exactly sure what Seven's process looked like during all this, but I imagine it was something like this:
Except with more plasmas and scrollers, and my reorchestrated Second Reality score.
Somewhere around iteration #3, Seven sent me an email, "Ahum, I notice once I actually try to play the music it sounds completely random, like one pattern from somewhere at the end plays first, and the some random notes with a lot of silence. The easy_exe gives me the same result, although the cr4.xrns plays fine in renoise. Can you confirm the music.exe that is generated by easy_exe sounds correctly at your end?"
I checked, and sure enough, the music sounded like a random note explosion. Like a John Cage piece for prepared piano, except using Clinkster sounds.
This was not good.
I confirmed the problem and started trying to troubleshoot the problem. I assumed it was some issue that Renoise had introduced during transcription. Maybe some errant hidden data that was breaking everything. It was my fault, I had simply been cutting and listening to the result in Renoise, but what I should have been doing is putting the song through the entire 4-step toolchain. If Seven hadn't been trying to build the entire production everyday to verify, we wouldn't known until it was much too late.
I stepped back through previous iterations until I found one that didn't break. Then I took the next iteration and cut all the patterns out except for the first one. Saved it and then put it through the tool-chain. It sounded fine.
So I did the same thing and kept the first two sequences and test. Fine again. I kept repeating until somewhere around sequence 69 or 70, it broke. And this is why Seven makes the big bucks. Using this information and the 70 or so version I had created up to that point (I actually ended up with a little over 100 different test versions trying to solve this problem) Seven pinpointed the problem to an issue in the Clinkster tool-chain, not Renoise!
It turns out that I had an instrument that had more than 127 note-volume-length combinations and had simply introduced so much entropy into the song that it broke during the Compile/Compress stages (Ed. Seven wishes I'd explain it this way "It turns out that I had an instrument that had more than 127 note-volume-length combinations, which is (although the documentation doesn't mention it) the maximum Clinkster supports."). Apparently, nobody had ever pushed the tool this far, we were literally pushing beyond what the tools were capable of at this point.
Seven narrowed down the issue even more, edited the asm code and sent me an updated clinkster.asm file and the problem was solved! If anybody saw this production during the compo, you might have noticed the "mutant Clinkster" during the introduction of the production. Now you know where that all came from.
No comments:
Post a Comment