So it was failing well outside my domains–in a native method! There wasn’t even a line number to have a look at. But was it because of something I did? I thought maybe it was because I wasn’t synchronizing things properly–so I went to make sure everything was properly initialised, nothing was done before it was due… and still it crashed.

Then I paid even more close attention and I noticed that the difference between ‘crash’ and ‘no crash’ was that before it crashed it always output a mHardware->setOverlay() failed with status -2147483648 message

So since I couldn’t find any solution or pointer anywhere, I decided to have a look at the native code–that way, I could at least find out what was that setOverlay() failed message about.

It took me a bit to navigate the code, since there are lots of messages and calls going back and forward between Samsung’s specific code and Android’s core, and I’m not sure I have totally understood how it works, but it seems that the firmware for the Nexus S (alias Samsung Crespo) requires that

• the preview surface width is a multiple of 8 (and at least 8), and
• the preview surface height is at least 16

That is defined in the check_fimc_dst_constraints function in mydroid/device/samsung/crespo/liboverlay/overlay.cpp

I changed the preview size to 8×16, and now the app doesn’t crash on the Nexus S, although there’s an unfortunate side effect: the preview is more visible than it was before –yes, it was visible. It was a 1×1 sized preview, and that’s why it was failing on the Nexus S (and probably any other setup with that kind of surface size restriction). Now I need to find a way to hide it… oh wait, I found it! The answer, on the following post :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