Per the Clinkster docs:
"You can use the Delay effect (under Track DSPs) with these restrictions:
- The "L Feedb.", "R Feedb." and "Send" sliders must be at the same position.
- "Mute Src." must be off.
- No L/R Output Pan.
- If you use the Delay effect on multiple tracks, you must use the exact same
parameters on each track."
I had cut almost all of the hand-made digital delays in the song (see Part 9) saving considerable space. But I figured, instead of adding them back in, why not use the Delay Effect instead and make this thing fully a product of modernity?
Like most things, anywhere the Clinkster docs say "you can" means you're going to use bytes doing it. It's also very limited, any track with a delay has to have exactly the same delay parameters, so I had to choose options that sounded reasonable on all the tracks I wanted to add delay to.
This added a mere 22 bytes, far fewer than adding the original hand-coded delays. This became Cut Iteration #7. I also added back some of the instrument doubling I used to bring the leads out in the mix. This was Cut Iteration #8, and because each new octave/instrument was another set of note-instrument-velocity-length combinations just a few notes added back 159 bytes. So by Cut #8, we were almost back to where we were with Cut #5, but hopefully with better sound.
Seven in the meanwhile was still experimenting with mono-vs-stereo playback. Using mono shaved a few bytes from the production as it turns out, but required more mutations to Clinkster.
I listened to Cuts #6, 7 and 8 in mono to see if they sounded reasonable, and though I wasn't thrilled with it, they sounded "ok" over loud speakers. I decided to give Seven the final call at the party place and gave him a choice of cuts and mono or stereo as he needed. At this point there really wasn't any more I could cut without making the song start to sound completely unrecognizable. I'm actually not sure which one Seven finally went with, but I was glad to be able to give him some choices so he could focus on coding.
Here's how it played at the party:
I couldn't attend the party in person, so hearing the crowd enjoy the song was awesome. I loved hearing people shout out and fill in the missing vocal bits, singing along with it and other mayhem. Most important for a competition, we did pretty well. We came in a close 2nd in a very competitive year. The post-party reaction was more mixed, I'm not sure that the modern scene crowd quite understands the technical limitations and the amount of effort that goes into fitting something interesting into 8k. After talking with a couple people, some even were confused that it looked so terrible for such a high resolution as 7680×4320. After correcting them that this wasn't a resolution category but a size category, the light seemed to finally click on.
Stranger to me are people who seemed angry about this production. I've never really seen or heard of people get angry at a demoscene production before, so we must have pushed a button somewhere. But it doesn't really weigh on me too much. Comments surrounding the absolutely amazing Commodore 64 remix are also quite mixed, even though it won its competition.
With productions like this, there's inevitably compromises, some are easy to make, some are hard. And of course this is a hugely compromised production. However, the entire production fits into less space than some of the intermediary images in the original! It's my hope that this series has helped provide some insight into what some of those compromises were, why they were made, and how they shaped the final production.
(Since you've read this far, here's all the cuts and troubleshooting mixes from this series).
Hey, from someone that has been doing 4ks for 12 years, congrats for the write up and the 8kb, it looked cool in the compo :)
ReplyDeleteThanks! Hope you enjoyed it!
DeleteSure, it was nice, and I expected it to place first (and voted accordingly) :D
DeleteThanks, it was a close vote among tough competition!
DeleteThanks a lot for the write up!
ReplyDeleteI must say I'm quite surprised not more of the C64 version could be used for inspiration. Just having to reduce to 3 channels means KB already did a huge job of sacrificing notes...
Also, you keep talking about entropy and all.. and also splitting interleaved echos into their own channels. Have you thought about dedicating channels only for those echos? That way you can have one volume/pan setting for the echo, so it sounds well and doesn't require an explicit per-note volume setting? Since it would be just like the other pattern but a couple beats later, it should compress like a charm, maybe not as much as a delay effect, but still...
Further on that topic, what about splitting the drum instruments into their own channels? That way you can have a fairly simple kick + an extremely simple hat that compress to nothing + a more complex snare but nowhere near as complex as the full drum pattern.
Thanks for the comment!
DeleteI was also really surprised at how big the C64 version was. But it makes a kind of sense, if you consider the instrument data for the SID chip is pretty tiny, he still tried to preserve as much of the note data as possible.
As for splitting/merging channels, it turns out Clinkster creates new channel/instrument combinations whenever you use an instrument outside of its expected channel, thus increasing size. It seems to be designed to optimize for a more DAW-style (1-instrument, 1-track) use-case. So splitting echoes across lots of channels simply causes Clinkster to generate more channel/instrument/note combinations (more space!). The best answer is to just let Clinkster's echo effects handle it.