Thanks to all of you who were in the seminar!

Looking forward to some Renoise-powered productions :-D

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?

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!!

However, the a-ha moment has been more of a grumpy “TSK!” moment than a long list of joyous exclamations. Remember I told you that the sound was very stuttered? I went layer by layer commenting out its code and replacing it with a couple of lines that would output a simple sine wave into the output buffer provided to each layer, so that I could distinguish if the gaps were created by the synth or if I was touching some pointers inadequately. Everything seemed fine and I couldn’t understand where did the stuttering come from until I thought: if there were true gaps, there shouldn’t be any audio AT ALL in these “gaps”. But there is audio. Where does it come from, if I am zeroing the data in each iteration…? And then I thought: I’ll check this anyway, although I’m sure I’m zeroing the buffer…

… and guess what…?

I WASN’T!!!

Since the output buffer is pre-allocated (it’s a member of SorolletPlayer) so that I’m not creating and assigning vector space on each getBuffer invocation, it maintains the values from run to run, unless it’s zeroed. As I was just accumulating on it the values that the voices had just rendered, what I was doing in fact was adding values to a non-empty array. And that’s why I was getting those strange results.

So it was a suuuper silly thing, as I expected it to be. Why didn’t I find that yesterday? Maybe I took that for granted. Today I probably approached the code in a more inquisitive way :D

The good news: I could finally render a full dump of a test song. Yeah!
The bad news: I haven’t got it totally working with the “real time” part (I’m still fixing a couple of leaks that Valgrind has graciously told me about) but at least things are moving again.

P H E W !

For a moment I was even considering going back to BASS or Fmod :-S

Then I have added a new method which, once the song has been loaded, parameters having been passed to the voices, and pattern data prepared and in memory, goes through the order list and the patterns and builds a list of events, sorted by timestamp.

When playing, I check if I have any event(s) to process in this buffer and if that’s the case, they are processed and the internal pointer for events increased. This is a lot like the deltaFrames concept –actually I would say it is exactly the same, but maybe they differ at some point–, and it’s way more granular than what I was doing before (playing one row at a time, just like a tracker).

This is also pretty similar to using a MIDI style list of events… and I believe that it’s also the same convention that mighty kb’s V2 follows too.

Now I just have a few details to polish and I’ll begin to work on more interesting things such as pattern effects! :D