soledad penadés

So the quest is set, the aim is clear: create something for Breakpoint 2010. There won’t be another opportunity; not at least under the Breakpoint umbrella.

The organizers have expressed publicly they don’t wish to organize yet another edition of nowadays biggest demoscene event, so it’s now or never! (At least until a new event this good takes off).

I already have had stuff of mine shown in their big screen. But that was before the true Big Screen, with capital letters. The 70 square meters one. I must release something, I said to myself.

Of course, this means that in a way, I’m going to break my own self-imposed rule (I will release things when they are done), but I’m working in a slightly pressurised scenario in order to finish the demo before setting off for the airport.

I have decided to keep a somewhat sporadic short demolog to keep people informed of what I’m doing, trace’s style. Hopefully it will help/force me to do things, daily, so that I don’t slack or procrastinate, and maybe you may help me too when/if I get stuck somewhere ;)

I’ll keep things short –this is probably going to be the longest post in the series– so that writing here doesn’t starve me of time to code.

This is the current status of the project:

• the theme is approximately set, but I won’t disclose it here
• I’m working on converting my on-its-own rudimentary OO-C synth (sorollet) to a bit less rudimentary C++ synth that can be embedded and interfaced, VSTi style, so that I can sequence everything from Renoise and play with parameters and settings in real time…
• … and convert Renoise’s Song.xml (inside the .xrns file) to my own data file — kind of means recreating a simple tracker which follows Renoise conventions (Lines Per Beat for example). I have taken a look at the Song.xml file, extracting and using the relevant data seems easy, specially since Sorollet was already using a tracker style format.
• So far I have managed to compile a VST plug-in in Linux. I had to solve several issues like having to compile for 32 bit while using a 64 bit OS, because Renoise is 32 bit too, gdb not willing to cooperate most of the times, the VST SDK docs being scarce and incomplete and not ready for Linux and etc, but I’m slowly progressing. Now I have a basic synth that can play sines or triangles, and transpose octaves. Awesomeness!
• This means I’m not using an mp3 this time. Could this fit into an intro? Maybe, but I don’t want to sacrifice code readability in order to make it fit into an intro… I’ll be more than content with making a demo!
• I need to find a way of producing a working Windows executable. Sadly, party organisers won’t allow a non-Windows .exe to enter the demo compo. Big BOOOOOOH for them. I have thought of different solutions, the easier is to install mingw in a VirtualBoxed Windows I’ve got, recompile my sources there and run the exe in my main machine, using wine. But I still have to try that, and I hope it works in Windows Vista :-S
• I still haven’t thought about the visual part, I fear I’ll have to script it as in ye olde times –no time for writing a visual timeline manager–, but I will probably use Lua to alleviate the pain.

Complimentary screenshot:

More later.

If you paid close attention to every single word I placed on the latest demo sources releases, you may have probably noticed that there was something like a count down at the end of each one of them. Some people were placing high hopes on that, specially since the biggest party in Spain (euskal) was getting closer. They thought I was preparing a demo, but they were slightly misled :-)

Consider this the ZERO plus the BANG in the countdown. The key question here is: now that I have released all these freak lines of code, what am I going to do?

Well, the answer is way fuzzier than the question. While I was making sure that the demos worked on my system, I realised that I was getting increasingly annoyed by the usual demo development loop:

1. change something
2. compile
3. execute
4. wait for loading
5. verify results are satisfactory; if not, go back to step 1

We are now in the instant feedback age; we as users and even developers expect everything to react pretty much in real time. Having to wait for all those things to happen is just cumbersome; delays are unacceptable. So, the wish number one for any future developments is that I would like to avoid said development loop. Which gets translated into I would like to have some kind of visual/interactive environment.

Another thing that really frustrated me was the fact that I have a nice 23″ screen, able to show up to 1920×1200 pixels, but pretty much all my demos were prepared for a resolution of 640×480; 1024×768 in the very best case. So trying to watch them full screen here was at least annoying, because when the textures were scaled, they looked really ugly, even with interpolation and all that. This could be solved with a couple of very cool features: procedural texture generation and using vector graphics for everything else. That way you never lose detail.

As musician first, programmer second, my other main concern is the music, and the way it is generally used in demos, and how inefficient is everything. It usually works like this:

• Musician creates a song, saves it in MP3/OGG format
• Coder takes the song, places it in the demo, looks for ’synch’ points, codes everything around those synch points

Usually the ’synch’ points end up being an approximate duplicate of notes in the song. So effectively what the coder is doing is redoing the song, which I think is silly, apart from tedious and boring and a direct attack to the DRY principle that I strongly advocate.

Why not use directly the song’s data instead of trying to replicate it? Of course, this means I would be using synthesized music as well, but I do not think that it would be a limitation, but a feature instead. You could be able to add new events, change the BPM, etc… without having to worry about keeping the classical ‘events list’ up to date in the code or demo metadata. And the visuals could be way more reactive than they are nowadays by just using the FFT information in the best case.

And while we are on it, why should we stop at the non-interactive line? Imagine all the above features were already implemented. Would not be a pity to not to be able to experiment with new angles and values? Add new stuff on the fly, new events, new effects, new scenes… something like a jam demo session? It could get deliciously crazy, since your creativity would not be blocked by the demo development loop, and would get instant feedback instead, inspiring you to experiment with more ideas (it could also be mentally exhausting, but that’s another story).

I wonder if the demoscene is negating itself some expressiveness by limiting itself to non-interactive pieces. As someone said once (I think it was trace), you can’t really convince anyone of the greatness of the demoscene/real time way if you don’t allow them to change the camera angle. Up until that point, they might be easily suspecting you are simply streaming HQ video from your server.

I’m already imagining it: some kind of visual audio real time sequencer and synthesizer. It is well far away in the future but it’s what I would like to do. I think that would be my master piece!

And before you diligently inform me, I do already know that there are several projects, like vvvv or PureData, which aim to do exactly (or pretty much) the same I am thinking of.

But arguing that is just negating the pleasure of learning, of investigating and researching how things work, and then make them happen or make them even better than existing alternatives. I do not want to allow consumerism permeate my mind: I strongly oppose the belief that we should just go and buy something that already exists, then when we get bored of it, go buy something more shiny. That’s just not me :-)

So after all these lucubrations I think you may have already deducted that there won’t be a complete demo/intro/whatever in the near future, since I’m going to take things very easy. There might be proofs of concept, samples of things that I implement, and etc, but I do not want to force myself to release stuff just because there is a party, specially after painfully realising that pretty much all my demos are in an atrocious unfinished state due to the fact that they were quickly hacked assembled together in order to meet a party deadline. I’m going to embrace John Carmack’s philosophy: things will be released when they are done!

I have just set up a page for to_the_beat, the 64k intro I released at past euskal 16.

Since the intro graphics are quite basic, I decided to focus on the software synth the intro uses (sorollet) instead and reveal some of its not very complicated secrets.

The sources of the intro and synth are also available so that you can learn what NOT to do when coding real time stuff ;-)

Joking aside, if you want to see the source of a small software synth, this might be useful, since I haven’t optimised it too much and it’s still pretty readable I think.

Let’s see what happens in future versions…