Posts Tagged ‘cpp’

20100309 Breakpoint demolog, day 34: VSTi+Renoise working again

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!

20100308 Breakpoint demolog, days 32-33: moving to Windows

Since I’m going to be away from my main computer for a few days, I reformatted mrdoob’s laptop so that it could run Windows. Mind you, this is a Macbook Pro computer, which means that installing Windows is a long process, specially if you make a mistake and have to reinstall Leopard from start again!

So it was a “very interesting” Saturday evening+night: the computer doing its stuff, while I cursed Bill Gates and Steve Jobs indistinctly. You can’t appreciate enough how fast the Ubuntu installation is, until you have to reinstall Mac OS or Windows again. How can they be that DAMN SLOW?!

Anyway, I managed to install Visual Studio and all that. I have even installed cygwin so that I can keep using a decent command line and git. I have set up a remote repository on a server, so that I can share the changes between computers too. Not that I think I’m going to touch much code in the Linux computer, but it’s good to have that. Just in case the laptop data gets corrupted or something :)

I have fixed the couple of bugs I had from Friday –nothing too serious, just some errors not being checked– and the “demo” is working as expected: the song is loaded, a simple triangle is shown in the screen while the song is playing and when it finishes, the demo exists. However there’s a bit of cracks and distortions here and there… I might probably have broken something in the SorolletVoice class while fixing something else, so what I’m going to do is to compile the VSTi for Windows, and compose the song using Renoise on Windows. After all, it’s all the same format at the end… and that way I can make sure that what I heard in Renoise is more or less the same than in the demo!

And the final paragraph is dedicated to Iq: the size of the simplest program that uses my player (the one which does a WAV dump) is 86kb, Release. When kkrunchified, it goes down to approximately 31kb. But my demo is using SDL… and that simple program doesn’t even open a window or output any sound anywhere, so I tried to load your 64k framework in Visual Studio 2008 –with the hope of using it as a base instead of using SDL– but it systematically refused to compile :-( There are errors in some structs from the events file, but I can’t quite get why, because they look perfectly fine to me. Maybe you’re using VS2005?

20100306 Breakpoint demolog, day 31: the culprit has been identified and reduced

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

20100227 Breakpoint demolog, day 25: eventList

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

20100226 Breakpoint demolog, day 24: going backwards X-(

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