Hey, almost one month that I have posted a message about coding a 4k intro for BP 2010. So what's going on?
Well, I'm happy to be close to the end, fighting with the last available bytes, working on the music with ulrick, running, and rerunning several times the intro to work on the synchro. We are almost done now, but It's far from what I was expecting to release! I have developed around 4 to 5 scenes but was forced to only use 2 of them. I will publish a complete detail about compression ratio/vs part of this intro after releasing it.
We have finally worked with 4klang for the music. This synth is very well designed and very versatile. The only drawback would be the total size code + data that goes around 1.4k to 1.5k. That's a lot and It didn't help me to inject more scenes. I would expect a synth code + data to be around 1k to 1.1k max, of course with less flexibility and probably a sound that could not be as rich as 4klang, but still with something nice. I have started to implement a small softsynth player based on my previous work. But I have suspended this laborious task, as I know that It would have taken me much more time to plug everything in a VST (although It's quite easy when you do this through .NET), design a simple GUI, file formats, develop a cool sound bank, test it, debug it....etc. That option was too risky, so I have postponed this work after BP.
Anyway, from what I have seen while starting coding this softsynth, is that It's possible to go around 600 byte for the player... and probably 400 byte for the music + the sound bank... but I will be able to confirm this when I'm done with it, It's only a projection. The fact is that a stackbased synth is powerful, allowing for complex sound design (and synchronization/modulation, nicely done in 4klang) but If you look closer at it, you will see that most of the synth part are almost common to all sounds : While a stackbased synth allows everything, pragmatically, a sound respond to some classic design rules : a collection of cascaded/combined oscillators/noisers, few insert-fx (and the most common ones, filters, stereo delay/reverb), and those rules have a straight translation to a stack based system that you will recognize immediately among different instruments (and this pattern will repeat). This "static" pattern is probably more efficient for a 4k, both for the code size and the data, allowing for example to "bitify" data organization. Crinkler is using exactly this kind of static pattern (I still do have to write an article about it) : instead of having a generic context modeling compressor, It's using some kind of semi-dynamic/static context modeling that is in the end, much more powerful then it's generic equivalent (from what I have seen, a generic context modeling decompressor code is around 2% to 4% larger for a 4k, not a huge deal, but 2 to 4% is around 80 to 160 bytes for a 4k.... and that's a lot for a 4k). Of course, this is not only a question of some static algo vs more generic one... it's also a question of being able to produce a well done code-size optimized x86 assembler code (and crinkler just for this, is a masterpiece).
So, 400 bytes would have allowed me to add a scene, add some nice text... :) But ok, we had to move on! I'm not going to complain about 4klang, when rudebox was so impressive, using exactly the same synth. It's possible to code something cool... and in the mean time to get some benefits from 4klang sound quality, so I found this an acceptable compromise... and a nice challenge!
Anyway, see you soon at BP 2010!