What are we judging in these compos?

Are we judging the composer’s ability to use a synthesiser and build a pleasant and/or skilled composition with it…

… or are we judging the features of the synthesiser?

The problem is that if we are to judge the entries by the musical abilities, and the entry is based on a synth not programmed by the composer, they could perfectly submit that very same song, rendered into an MP3 file, into the MP3 compo. And get done with it.

But we have reached a situation where 50% of entries for these competitions are running V2 or 4klang. This leaves everyone else in an unfair position, and not only that, but it also turns the competition into an uncompetitive parade of entries based on the same set of features, which in other words means that the majority of songs sound the same, which is booooring.

I think –and I’m not alone– that party organisers would do loads of good if clarifying the rules. Just add a little sentence like “Composers can only use their own or their group’s synth” and it will make this competition have sense again (or for the first time!). Otherwise, this is nothing else than a glorified Farbrausch vs Alcatraz compo, with the occasional outsider making it into the compo.

Here is the list of entries for this past Breakpoint’s exe music compo:

Some of the entries do not state the name of synth they use in the .nfo file (although that information was shown in the big screen at the time the entries were played), so I write from what I can recall. Hopefully you’ll get the point.

Oh, and allow me to reiterate that I do not write this because my entry didn’t rank higher. I realistically knew I couldn’t compete with the rest of synths, if only because this version of my synth has only two months work on it, and most of the last month was dedicated to fighting with compilers and counter-productive crap like that, instead of working on getting a better song and nicer features.

Still, I’m quite happy because quite a few people got in touch with me and asked me about the synth and whether they could use it and all that after listening to my entry. Besides, I feel super-empowered by the simple fact that I built a synth by myself instead of relying on somebody else’s.

You don’t get this warm and fuzzy feeling when using V2 or 4klang :P

Your wishes have been fulfilled – Sorollet V2 it’s finally out, for you to enjoy (or suffer, depends on your tastes, but hopefully you’ll like it).

The project comes with the song that I released for the Breakpoint’s 2010 newschool exe music compo, Bizarría sorollosa – which can be listened to here too:

Bizarría sorollosa by supersole

If you’re running Windows, you can also download and listen to the song running real-time in your computer, by downloading the compo entry (the zip is huge because it also includes an .ogg rendering of the song; the .exe is just less than 12kb). If you want to listen to it real-time but are not running Windows please download the source and build it yourself — it should be only a matter of typing scons on a terminal, or pressing the build button if using Netbeans like me.

My entry itself ranked last, which was a bit of a disappointment, although there were fantastic entries on the compo which totally deserved to rank superhigher than me. But more on that on a future post…

I’m going to prepare the zip with the exe, the .ogg dump, readme.txt and all that so that I won’t do it in a hurry, in the partyplace.

After all I have to think about a way of having the synth ready for 32k exe music compos if need be, but specially get it working again for embedding it into a VSTi, using the same code in both places. So that means I’ll examine thoroughly iq’s framework and pick only the pieces I need. Sorry for ripping open your framework, iq, but it’s in the interests of science! Hopefully I won’t end up with Frankenstein-esque code…

The final step will be to upload the code and all that to my github repo and release it for general enjoyment (heh). I might also provide a linux build of the VSTi but after using fighting with Visual C++ for a few weeks I don’t really feel like providing a build of anything for Windows. On Mac… I have gcc installed in my PowerBook, so once I manage to get this code compiled with gcc again it shouldn’t be too hard to compile it for Mac OS X. But I can’t promise anything; computers are unpredictable, and computers+code that one didn’t write (i.e. the VST SDK) are even worse ;)

The framework has several noise functions, intended to be fast, very fast. But for some reason they also generate NaN values from time to time (1.#QNAN00 in Visual Studio’s jargon), and this was making things go crazy whenever one of those values appeared (read: distorted). I solved this using another noise function, from this article that dario_phong mentioned a few weeks ago:

This one doesn’t produce any NaN values and seems reasonably fast.

Funnily, the same article gave me somehow a hint as to why the synth sounded awful when in release. It seems the framework uses the /QIfist compiler option in release and that produced a very rough float to int conversion, hence the cranky sound when in release.
But if I removed the option, the compiler complained about a missing _ftol function. So I solved my problem in a slightly slow and cumbersome, and probably not very elegant way, which was to add a new function using the assembler implementation provided in the same article:

It actually is in my MathUtils class, as MathUtils::floor. So everywhere that was a construct like this:

I changed it into

I am unsure as to whether this is a good idea or not, but the synth sounds properly now and the performance doesn’t seem to have increased or decreased, so I assume that at least is OK.

The only minor issue is that the assembler instruction belongs to the SSE instruction set so old processors (<1999) might not have it, although they probably won't be able to run the rest of the code anyway (performance wise speaking, it is a bit of an unoptimised resource hog :P). Also, I haven't tried to compile these last changes with gcc, so I don't know whether it will be OK with this inline assembler syntax. I think it should be fine and won't ask me to use the AT&T syntax instead, which I find pretty horrible by the way. But there's something for sure, I'll have to look for an alternative if I want to compile this in my PowerPC powered PowerBook :)

On the composing side, I've got about 2 minutes of raw, unpolished and unadorned song. It's turning out to be quite weird and a quite bit "in my style", so if there are any supersole fans in the audience they might easily recognise the song even without looking at the screen at all, haha!

I’d love to finish the song tomorrow, fingers crossed!

We went to Spain for a few days (hence the plane meditation title of a previous post) to visit family and have a taste of that hell-in-Earth celebration that are Fallas, and I could keep productively working on the demo for the first few days. After that, things just stopped going so smoothly –or I was too distracted– and I lose a lot of time with trying to compose a song which could work for a demo, with my synth. Unsuccessfully.

After a fruitful conversation with mrdoob, I understood that I couldn’t have the cake and eat it too, so I decided to aim for a cupcake instead. Therefore I’ll skip the visual part and focus on creating a song for the executable music compo.

Which on one hand is a pity since I really wanted to fill that gorgeous huge screen with my stuff, but since there are always a TON of demos I guess it’s better to not to add another half-finished demo to the competition.

With that in mind I began to make my code fit in 32kb. I tried first to do things from scratch and learn in a few hours how to make that waveOut Windows API work. At which I failed miserably. And I didn’t want to install the DirectX framework (and going through the genuine windows validation thing meanwhile) just for this, if only because I fear it would ruin my Windows installation.

Hours later I remembered that His 4k/64k Majesty iq had helped me to fit my previous intro into his 64k framework, and the code is out there. And amazingly, it compiled without a complaint from Visual Studio 2008! (unlike the 64k framework sources that are in his own website).

So I spent yesterday changing the code to use pure vectors instead of std::vector, devising alternative data structures to avoid using std::map and things like that, since the 64k framework doesn’t use the standard c++ memory allocation, and everything with templates just won’t compile. And since my previous code assumed that I would load the Song.xml directly, I also wrote a new importer from Song.xrns to Song.h, using python, so that the song data is extracted and converted into a long array of floats, prior to compiling.

Now I have an executable that when compressed only uses 8-9kb, including a semi-elaborated song, so there’s plenty of space for more elaboration if need be. Unfortunately the sound isn’t exactly what comes out from Renoise –the code being more or less the same–. It’s got something to do with the implementation of math functions that the framework uses, since we had a similar issue when we ported the intro to Windows: things would sound weird and distorted in Windows only. I’m tracking things down by using simple sounds and testing them separately, changing one parameter at a time. It’s a bit slow but it’s the only way of tackling this.

Wish me luck! :D