soledad penadés

Today’s been quite productive and I feel I have implemented the remaining “bare minimum” feature I [realistically] wanted to achieve for this demo: pattern automation!

So now I can draw curves for any parameter in my synth, in any pattern, with them associated to an instance of Renoise’s Automation Device, and they will be replayed when running the demo. Only points and linear curve modes are implemented –I never use cubic, even in real life renoising, so I won’t miss it–. But it’s enough for making songs way more lively and varied, and I am reaching the point in which I feel like running out of time, so feature-freezing at this point is a very sane idea :)

I have also added another little neat, experimental feature… that I won’t disclose yet in the interests of creating a bit of expectation! I haven’t tested it too much yet, and I’m not sure how well will it work when I submit the synth to serious (stress|test)ing, in order to compose the song, which is what I’m going to do in the following day(s).

In the compiler front, Visual Express and I haven’t come to amicable terms yet, but I’ll leave the complaints for another post. Only two words and a question mark: No refactoring?

Things have improved a lot compared with yesterday’s status. I have fixed several sound bugs and whatnot’s, and have added support for volume changes and note offs in the patterns. Silly as they might look, they actually are quite important :-)

In fact, in what regards to volume (the volume column, more specifically) my player is slightly more feature richer than Renoise, since if you send different volume values to a VSTi in Renoise once the note has been sent, it doesn’t do anything, while my player acts accordingly and updates the volume for the corresponding voice. This can be used for the old tracker trick of having a rapid sequence of 64, 00, 64, 00, 32, 00, for example, and since it’s always quite handy for me, I have implemented it even if that’s not exactly what Renoise does. Not sure if I’ll repent later!

I have also begun work with reading and parsing the automation envelopes that I can create with Renoise in order to change synth parameters on the fly, with the Automation Device. I looked into CC changes but they looked just too complicated, while the Envelopes look simpler and more granular/synthetic, so I went for that approach instead. I am almost done with reading the data, I only have to let the patterns know about them and use it when playing :-P

Filter cut off sweeps, there we go!!

I managed to compile the VST instrument for Windows. There were some odd differences between Linux and Windows in the main.cpp side of things, so at the end I just made a new main_windows.cpp and forgot about trying to wrap incompatible things with #ifdef/#endif pairs. I also had to add an esoteric .def file so that Renoise would recognise the .dll as a plug-in file…

All in all, I’m finding Visual 2008 superverbose, superboring and superslow to work with. I don’t know if I had just idolised VC6 but I don’t remember it being so cumbersome. For example, the autocompletion or “intellisense” thing doesn’t show me useful stuff most of the time… it usually shows me a list of low level Windows constants that I obviously don’t care about, instead of showing me classes from my project. Also, the keys for triggering autocompletion are super odd (ALT + right arrow) instead of the usual CTRL+Space. I haven’t found the option for automatically adding matching braces, so I have to do it manually. The options and general semantics are annoyingly microsoftive (e.g. “Solutions” actually means “a generated binary”), editing project properties is annoyingly slow, and etc, etc. Even the XCode configuration panels look nice compared to this!

What is also possible is that I have got accostumed to Makefiles and the whole idea of going through a series of tabs and trees and options and blablah just looks silly at this point. We’ll see if I end up liking it at the end…

End of the mini-rant and back to the demo: I got a new version where a simple representation of the left/right buffers is painted on each frame. That’s the most advanced graphical stuff I’ve done to date in this project, hehe. The sound is quite saturated in comparison with the output I get in Renoise for the same song. It’s probably due to the fact that in my code I’m not doing any clipping in the output of SorolletVoice and am adding all together in the mixer, but Renoise is probably clipping each voice internally when it gets the output of each VSTi instance. So I’ll add that tomorrow… otherwise as soon as more than one instrument is playing at a relatively loud volume, hardly anything can be distinguished!

Unfortunately I have had to “pause” these developments while I finish something else I wanted/expected to have finished two days ago.

With a bit of luck it’ll be soon in your screens. That is, if you have an Android phone! :D

In the meantime, a couple of clarifications:

• This is not going to be an intro. Please stop asking about size… I don’t care about the size of the exe, I don’t want to be worrying about packing and squeezing more bytes in less space. Specially since I intend on using the synth on real-life VSTis, I don’t want to sacrifice audio quality for space constraints.
• If you want to write a player using renoise as a base, it doesn’t harm to understand how trackers work! Anyway, there’s a lot of renoise tools developed by external developers. Some of them have source code and might be useful for anybody wanting to understand the file format… but I find it easier to just open a song file and having a look at the xml.

:-)

Began work on getting audio from more than one voice at the same time — by calling the SorolletPlayer::getBuffer function for the first time! The problem is that currently the body of the method is this:

A tad too simple for my purposes, but had to sort a few things before calling the Voice instances — such as for example creating those instances first! And sending them the parameters, as read from Song.xml.

It seems that it is working; at least I’m not getting a dreaded segmentation fault on load time. Although no sound yet (for reasons mentioned above ;)) Hopefully tomorrow…

I have also been researching a bit more on the unzip issue. Turns out there are two main options, which are to use zlib, or to use libraries which provide an easier access (or rather nicer interface) to zlib. I am slightly bemused that there’s not a simple function/library somewhere out there that can perform decompression in a portable, simple way. And with that I mean something that can be embedded in my code, TinyXML style, without having to build a .a or .lib first and then linking it, or having to install libraryname, and libraryname-dev prior to linking it with my executable, or having to carry a .dll or .so around, which frankly I dislike.

So maybe I’ll just add another step in the build process which picks the song, decompresses it and moves the Song.xml file to the data/ folder in the demo. Ah, the joys of having a decent command line!

(Deep down, I am pretty sure there’s a nifty library for unzipping files which has been implemented by some anonymous and hard-working 13-years old Japanese guy, and has even bindings for ruby just in case you’re not happy with the defaults, but I can’t find it because he doesn’t speak English and I don’t speak Japanese either).

Today’s output is pretty much like yesterday’s… Stay tuned! ;)