Stuart's Summer Bursary

The first half of my summer bursary was mostly spent learning new software. I learnt how to develop applications on the Mac with XCode, and on Linux with KDevelop. I learnt how to use CVS, a really cool thing that helps you always have a functioning version of your programme. I'm also becoming more and more familiar with QT, the multi-platform interface builder.

The hardest thing I had to do was understand someone else's code. I knew commenting was important before this project, but I really appreciate how important it is now! Becoming familiar with someone else's style and the way they think takes a while, and it's tough. Understanding what's going on in their programme is also difficult, and it took quite a while for me to get to grips with things. I now have a pretty good idea of what part does what, even if I don't understand how things work in places (ie, getting data to and from the sound card).

For the last part of the five weeks, I was restructuring the GUI elements of the programme, trying to make it easier to add in new widgets (after all, that's what I was here for). I used all my 346 skills in adding some more classes in, which now allows us to do things more easily than before (by means of abstraction). We shouldn't need to do any casting. Well, not much, anyway.

I implemented my first own widget in the last week, the "pitch compass". I think it's really cool. It didn't take too long either, which is hopefully a measure of how successful I was in restructuring.

I also began working on making the programme "smarter". Adding a new widget in is much easier than before - the programme generates some of its menus dynamically, which means when you're adding a widget in, you only need to change a couple of things.


The first five weeks of the bursary were mainly educational, but I got quite a bit done in the last two or so. Hopefully in the next five, I can implement some really cool widgets so my work is more visible rather than behind the scenes.

The good news is that CVS is up and running. Things are going in and coming out of the repository just fine. If I screw up, I'll be able to go back to a version easy as anything.

However, the bad news is that we've pretty much had to ditch all the stuff I was working on last week. I was working on a different version than what was in the old CVS repository, and when I tried to add my stuff in, all hell broke loose. Turns out there are some pretty significant differences between the two, and we ended up deciding to just go with the later one. So, I've got a new programme to understand, and this one doesn't play sound. Yet.

I'm going through the classes, trying to understand what's what. The sound stream structure of this version is quite different to the older one - that's something to get my head around. This one's better - there's a Channel class, for instance - but it's new.

My task is to get it to play sound, but I'm not sure how that's going to happen. I'm stuck at the moment. I figure I'll just go back to working out where everything is.

Phil worked his magic yesterday, and we tracked down the bug that was preventing the microphone from working properly in MacOS. Turns out some code had been copied and pasted into the wrong place, and the programme was never reading buffers. That's fixed now, with some help from an old version of code.

I found a bug that meant the programme would crash after a while. We tracked it down to be in a widget, that ended up segfaulting because it was trying to access some memory that another thread was changing at the same time. Easily fixed, and now the programme isn't nearly so fragile.

Today I've been mainly documenting the code. It's a very slow process, but I'm getting there. I'm developing a good understanding of what's going on with it now - I'm not scared of the code any more! I'm renaming variables and classes now, so they'll all have a consistent naming convention.

I'm almost beginning to look forward to making it work on Windows now that I know what's going on. Once you have a clear picture of what each file is responsible for, things get a lot easier.

The app is currently 'working' on MacOS. I say 'working' because although it comes up, and everything responds as it should, the analysis isn't too flash, and trying to use the microphone at all crashes it.

I was quite pleased that it compiled - for some reason, the Makefile generated with qmake doesn't have the environment variables working properly. This means that every time I use qmake, I have to do a find and replace for $(QTDIR). Dunno why. It's just a little thing, but indicative of the quirks that can happen.

I've spent an hour or so tracing the execution of the programme, working out how the buttons are all set up (easy) and how the audio comes in (not so easy). I miss my multiple desktops from linux so much - the mac seems to be making things as difficult as possible for me. Emacs isn't very nice to use either - there's no speedbar.

I'm currently kinda stuck, so although I'm learning more about the programme, I need Phil's help to solve problems. After that, we should be fine.

Today, I was going to get the app working under the Mac (or at least get as much of it done as possible), but I was stymied somewhat.

Turns out, you have to compile QT with threads enabled if you want to be able to compile applications that use threads. I know, I know, sounds obvious, but it's the kind of thing you'll get wrong once and never forget. Especially as the dang thing takes so long to compile.

So, I occupied myself with experimenting with QT, trying to make applications go nicely etc. Turns out it's a little harder than it looks, but I began to get some things working. I'm in the process of making a model-view-controller app, but I've had to stop for the moment while I start QT compiling (again).

The worst thing about QT is its compile speed. It has a preprocessor, which goes through and makes all the special QT keywords work properly. This means there's an extra step, and while it's not too slow, it all adds up (especially when there are a zillion files to compile).

I'm looking forward to getting things working tomorrow.

It looks like we're going to be using QT for designing the interface of our programme. This morning I've been reading over the whitepaper for it (it had finished compiling when I got here - wonders never cease). Here's what I've learnt.

QT is like Java in that it's object-oriented, and (supposedly) platform independent. This is good news for me: Geoff wants me to make the app work on Linux, Mac and Windows. It seems to have a lot of abstraction in it, which means creating stuff may be a little more complex, but I can use inheritance to do lots of the work for me.

Everything extends QObject. Controls extend QWidget. Everything in QT begins with Q (or at least, that's what it seems like).

All the common controls have reasonable names: QRadioButton, QCheckBox, QComboBox, QTextEdit, etc. They also take the underlying OS graphical display automatically: this means that when we compile on a mac, things should look like a mac, on windows, like windows, etc. They even support the different Windows families (XP and non-XP). One thing I'm not sure about is MacOS9 support - I don't think its an option. OSX has been around for a few years now, so hopefully this won't be a problem by the time we release.

QT also has LayoutManagers, just like Java. It looks like there's just three: QHBoxLayout, QVBoxLayout, and QGridLayout. The whitepaper claims that the layout managers automatically pick the best sizes for widgets, so they look nice when the window's resized.

An important aspect of QT is the signal/slot mechanism. This is a way to send messages to other objects, without knowing what they are or who they're from. Basically, you define the various signals in your h file, under a signals: section, and the slots under slots: section. You also need to have Q_OBJECT there - I think this is a signal to the preprocessor. Your class has to extend QObject, too.
You then implement both in your cpp file. When you want to send a signal, you just go emit function(value). You define what happens when you receive a signal by implementing your slot method, and doing the correct action.
Slots can ignore some of their arguments, so if you have a function with three, a signal that only emits one may call it. The compiler automatically chooses the right one, but I bet that function's gonna bite me in the ass.
You couple the signals and slots together in your app file, using connect. In the whitepaper, they do this:
BankAccount x, y;
connect( &x, SIGNAL(balanceChanged(int)),&y, SLOT(setBalance(int)) );
x.setBalance( 2450 );
If it can't find an appropriate slot, it spits out a warning, but doesn't crash. Phew.

Saving settings looks okay. You can use the QSettings class to do this - on Windows it stores things in the registry, on other platforms, a text file. I think Phil said he saw this, but he decided to write his own - I'm not sure why, I'll have to ask. It may be a good idea to do this, but I'm sure he'll have his reasons.

Text can easily be translated too: you put your text in a call to tr() and it looks up the right one. You have to define it somewhere, but if we want to internationalise, this could be an easy way to do it.

Greetings, all.

This is going to be a quick record for myself of what I've been doing each day for my Summer Bursary at the University of Otago, 2004/2005. I'm working on a project which is aiming to help musicians learn to play their instruments better by analysing the sound they're producing and providing visual feedback. It's mainly so I don't forget things, but if y'all want to hop on for the ride, you're most welcome.

Things probably won't make much sense from time to time. I envisage posting to this at the end of the day, when I'm likely to be tired. Any complaints, drop me a line.