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

Sometimes it’s just better to get away from the computer and come back to it a day later or so. While yesterday I didn’t do much in the productive side of things and I spent something like four hours like that, today I managed to identify what the insidious, mysterious problem was in half an hour. However, I can’t categorically say that those four hours were a total waste of time; probably staying there in front of the code helped into having it permeate my brain, which quite probably has been working at this problem (in a low priority thread, as I like to call it) while I have been doing totally unrelated tasks the rest of the day.

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

I “archived” what I had done until yesterday in a git branch and left it there to sit in shame forever, and went back to what I had a few days ago, without any actual player code yet.

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

I think the more than I try to fix this player, the worse it gets.

I find it somehow surreal – I can write a semidecent soft-synth in a couple of weeks but I can’t code a proper player!

Yesterday’s issue of not hearing anything is totally due to the player and its wrong timing. I’m not sending events when they should be sent, so nothing happens when it should be happening.

Also, when testing the synth embedded in the VST host, the host asked all the time for quite small fragments of audio (around 300-512 samples). But SDL requires something in the order of 1024 upwards to get a not-too-cracked sound. 2048 is safe. The fact is that a lot of things can happen in that long interval, and if your player code is kind of broken, like this one, you’ll miss events, like I’m missing. Events such as notes! ARGH!

I’m also quite tired so I think I’m going to leave it as it is today and will reconsider things tomorrow with a fresh mind… wish me luck! :-D