Here you go

Instructions: Take a picture of yourself right now. Don't change your clothes, don't fix your hair - just take a picture. Post that picture with NO editing. Post these instructions with the picture.

Computers, Music, Transitions

Both computers and electronic music are in the middle of a major transition, one that is pretty difficult to see while we are stuck in our coding and composing. Things move so fast these days that it's easy to forget how new these worlds are.

Computers

The other day I was trying to explain to my Dad why he has problems communicating with a programmer he's hired to build some cost management stuff for Access. He constantly tries to get the lucky programmer to explain how the company will be fine without him, and he never understands the programmer's answers. My solution is to hire someone to work with the programmer that can asses the flexibility of the data storage with respect to well-accepted standards (xml, rel-db, etc...), and have a (very) quick look at the architecture of the application To make sure he isn't writing spaghetti. Any decent coder should be able to do this in an hour or two, but why does my poor Dad not even know how to approach the problem?

It is my belief that the industry is just too young, and the benefits of deploying code now are obviously HUGE (games, iPhones, VCR's, toasters, life). Software just has not matured to the point that it makes as much sense to the consumer public as an appliance like a TV or a car does, so that when it breaks you just call the guy that comes and fixes it for an hour or two at his flat $60/h rate. Shit, we're even used to the idea of that costing 1.5 times as much as you expected, which is some confort. Software developers are more like R&D experts, since every couple of years there is a high likely hood that they will be dealing with a major architectural change - where their work *environment* has changed enough that they are not just sitting down and using their skills, but they are also adapting their old skills to match. Sorry mister C/Perl/MyLang coder, but we're still just going to pay you for sitting down and using your skills. I want an estimate by Monday.

The goal of our project is to build a virtual instrument, but we spend all of our time on basic stuff like figuring out how to move controls and show messages, just like every other mundane application out there. The following is my current bug list:

-artf21115 : PLAY does not replace current instrument when changes not saved
-artf21125 : Replace Dialog box Not Present
-artf19771 : PLAY displays wrong amount of available RAM.. dialogue box no longer appears
-Strange error box (!) when validating AU... same box comes up when loading saved Cubase project to. picture attached to email
-Artifact artf17139 : No sound when "unfreezing" Play virtual instruments in Sonar 7 Producer... now results in "FATAL ERROR" when unfreezing
-Artifact artf15670 : No Audio Output in Sonar with Different Languages.

All of these bugs are regressions, which means they were working at one time, but are not working now. Every one of our regressions are caused by a poor name choice or incomplete design abstraction that lead to errors in our code caused by new features. This happens because we never had enough time to do it right in the first place. Sound familiar? That's because being crunched under a tight deadline is nothing new, no matter what industry you are in. I think that the difference here is that the most basic design and development methodologies have not matured to a point where solutions can be read in a manual and reproduced under the deadline. We should be able to sit down with the task of adding a dialog box, make the change, and never look back.

I hate to always wrap this stuff into a "python is the answer" thing and I won't do it this time, because while python helps a lot, it (actually!) isn't the answer. Somewhere down the road this stuff will get better, even with C++ and other useless languages like Java. All the good toolkits make it easier, but ONE toolkit would make it great. If you need some windows and some buttons, there should only be one place to turn. If you need some sound, there should be ONE toolkit for that. Dig?

Techno

Along the same lines, music is going through the beginning of a similar young stage. While an avaid trance and progressive fan, I don't believe that we will be listening to this stuff forever. Think of modern electro as part of a transition period where we are developing new tools and learning how to use them effectively for the next phase, whatever that is. Music is a way to communicate emotions, and express ideas that can't be explained using words. A good musician is an artist who has also mastered the technical nature of a musical instrument, so when he or she wants to get dirty and do some expressing, they can devote their energy to that instead of how to get the instrument to work.

A lot of new songs appeal to listeners because they've got some killer sounds, and usually are produced so they get a lot of punch out of the speakers. Fact is that this appeal won't last very long, and the songs that really last are the ones that are great songs, not great sounds. Go listen to *anything* techno from the early nineties, and you'll see what I mean. Psychotrance is only 15 years old and I can't stand to listen to it any more!

Where is this going? Who knows, but there are a few things that have never happened before. After PC's got fast anough for pro audio, we have started going through an incomprehensible amount of new music. I listen to internet radio all day at work and never hear the same track twice. We are also nailing down the hardware interfaces and software workflow. Ableton live has contributed more to this than anything else, IMHO. Further, the amount of publically available audio code out there is astonishing. We are seeing loads of people playing with new ideas like algorithmic composition that will lay the foundation for the macro-concepts to come.

The reason that I think things will change is that music has temporarily lost its expression. This is a big deal because music *is* expression. If you want communicate to your listeners that your brain works like a computer and is recorded, automated, and predictable, then be my guest.

For example, when I sit down to put together a concept for a trance track, I slap together a 4x4 kick drum, a side-chaining compressor, and some sort of chord or bass. How much expression is involved in that? Almost none. The chord progression is done with a midi keyboard, and is quite effective for a traditional harmony, but that's about it. Ideally, the entire peice would more closely mirror what was happening in my heart and body when I first wanted to sit down and start composing. While some of you may disagree, I don't think that an absurdly robotic and inane representation of a rhytmic emotion is happening in my body. Confused? I know, I know, but a human heart beat is more acurately reproduced as a human-powered drum.

As we build and get more in touch with our tools the music will come back around to the traditional expressive stuff our parents grew up with. Maybe our brains will actually become absurd and robotic to match the music, who knows. What I do believe is that all this robotic music won't be around forever, and it will be replaced by live music sporting incredible human and technology interaction. Remember the chamber quartet or the drum circle? Good story tellers and bad story tellers? Free interpretation? Music is expression and nothing else, so I don't think we are supposed to go and get rid of all the boring recorded and automatically sequenced music. I think it will disappear on it's own.

Togetherness

Anyway, considering I write software and produce electronic music, this is important stuff. In some ways I think we are walking in the dark, assuming that current software and current techno are the amazing finalizations of our incredible accomplishments. The truth is it isn't the end - we aren't there yet - it's the start of something bigger.

I have zero insight for how music will evolve since the last five years have given us so much change, but software is another story. This industry is young, and we don't know what we are doing yet. Can you ensure that your validation tool will function with 100% accuracy? When the productivity expectations of the customers and the producers are equal, we've made it. Until then, "Yeah, sure, we can make that deadline."

Nostalgiske Tenker

I miss my powerbook g4 12", because it's the best computer I've ever owned. Finally I had a compact laptop with more than enough screen, a full sized keyboard that felt really good, and unix running under a beautifully simple interface. Geek talk? Yes.

The only problem with the powerbook is that it is slow. Bit-blips ooze like cold honey out of their frame buffers, and gcc burns through parsely like a lost kitty. Poor gcc, poor PyQt. My macbook currently does everything I need it to. Sure, concurrent disks would be useful but it runs ableton live and is very good for developing C++ apps. Fix the bloody macbook, apple! 12"! 12"!!

The other day I downloaded the Doomsday engine and loaded (my?) DOOM2.WAD (note caps). I'm re-united with some seriously old, and seriously fun gaming. I'll never forget the first time I got locked in playing a Doom 1 deathmatch against John Kew and Steve Houston at John's place on Arctic. I quickly built myself a K5 90MHz with any parts I could scrounge up - and I mean *scrounge*. We spent more time getting our machines to work than playing games, but I was skipping track practice the first time I tried it. 12 years later I finally got control of the addiction...or have I?

Lessons Learned

Having moved to a C++ project with strict performance requirements, we've spent a ton of time on build config and memory related issues. Not only is the majority of our effort not spent on writing features, but this "wasted" time also happens to be the most agonizing. Being a hopeless idealist and having nothing but subjective and difficult to argue cases to present to my boss, I thought I'd just try to put it all on paper to remember for the next go around.

Developing a modern audio plugin with good platform support provides plenty of code management challenges. The plugin formats we support are AU/VST/RTAS, the platforms are Windows, Mac/ppc/intel, and all 32/64 bit. No one has ever bothered to count the total, but I do know that it amounts to a big pain. We use XCode 2.5 and Visual Studio 2005, and have incorporated qmake to use qt for the gui into both. Our main targets are a standalone app or a plugin, which in turn loads a separate plugin for each of our products that you've purchased. This means you have to maintain several build configurations over several platforms, and they all behave differently.

Lesson 1: Separate features and config

Clearly define your problem domain, and try to separate your build and deployment environment from the development environment as much as possible. For example, our problem domain is to implement a high-performance sample playback engine and accompanying UI, so adding some new graphical classes and menus should not affect the build config, and visa-versa. When you write in C/C++, you will typically define config macros on the command line, add and remove files to be compiled, etc, and all of this stuff will change on each platform. For example, when I add a QWidget subclass, I have to add the files to XCode, add an entry in the qmake project to generate the meta source, add the meta source to the XCode, and do it all over again for Visual Studio.

Conflicting headers has also caused us plenty of problems. Our primary third-party libraries are juce, Qt, and python. Python and Qt conflict over the "check" symbol, and juce and Qt conflict over the T macro and others. The juce library is nice enough to include "using namespace juce" in it's headers, so we get conflicts with just about everything, including system frameworks like Carbon. To solve this problem I had to find the correct order of #include and #undef statements to get all the libraries to play nice together. Don't even bring up windows.h. Finding a solid scheme for including the fundamentals is very important, and you should never have to worry about it in your feature code.

In a nutshell, You should write features with 0% brain power spent on how your features will affect the build config.

Lesson 2: Unify your build environment

Managing your build configuration is a pain in the butt. qmake does a really good job of flattening the tool chain, but as long as you are using more than one compiler you are going to have to have conditional variables built into the build config. This is almost always the case when you support more than one platform.

If you can manage to flatten the config to a point where you do not need to separate changes for your different platforms, you've taken a huge step. Adding a new library to your code will cause a change to the config, so the cleaner the libraries you choose, the better. Qt, sip, and PyQt are examples of libraries that add little to no compilation and linkage config overhead to a project because their lack of dependencies allow them to be relatively self-contained. The sip code actually compiles with no special flags.

Lesson 3: Write modular code

I know all of this stuff sounds elementary, but it's all very important. The more black boxes you write, the less they will change. Our project consists of a few key components; the audio engine, the gui, the product plugins, and the target exe/plugin (of which there are many). Trying to meet our stupidly tight initial deadlines, our project manager originally had everything compiled into a single target for each exe/plugin. Granted, this would have fixed the symbol visibility problem that we are having right now, but it added significant compile time and the code behaved differently everywhere.

It doesn't really matter how much intertwangling there is within the bounds of each component (your boss is going to assign those bugs to you anyway and you'll just go fix them), but it does matter that your major components are well separated. We aaaalmooooost nailed it in our project by creating engine, gui, and product libraries, but we unnecessarily mixed the headers and instantiated objects from each in the target exe's. A better approach is to provide a single header for each library that includes only pure virtual classes and some global factory functions. These headers should not define any types, and should not include each other.

I Tilleg

I like using our project as an example for project management topics because it has some relatively tough requirements. The audio engine must be written in C++ because performance is top priority, and the gui code could be written in python. Given that the engine is as small as possible and 100% independent of the other components, we could have written a small layer to move all of the application code into python. That way we could have added and tested new features with little worry to causing crashes and compilation/linking related issues.

As a result, the two most interesting problems that I would like to solve are:

1) A 100% self contained AU/VST/RTAS wrapper with PyQt support.

For the plugin wrapper, a flexible engine => gui interface would be key for component communication, but also the build config for the compiled elements would need to require as few compiler options as necessary to make it easy to be compiled as a local target as opposed to linked as a library. This way, the developers would have total access to the code once it was included in their project and would not have to deal with any overhead related to integrating it into their projects. Including updates to said code could be tricky, but I'm convinced that the changes could be made small enough to remain manageable.

2) A concurrent python interpreter.

A truely concurrent python interpreter would allow the language to be used in a realtime dsp engine while simultaneously used for the user interface. This has been brought up before and is a point of contention for the python project since the GIL is really really tough to remove. I suppose if I was able to provide a patch with a build option to at least provide a concurrently capable interpreter the language could be used in very specialized multithreaded cases. This is a pretty specialized requirement though, so maybe that's good enough? We just wanted the language itself, and I could have easily patched the sip and PyQt extensions to accommodate the change.