Blog for Paul Malyschko at GarageGames.com

Headache - Early Adopter version coming shortly

Paul Malyschko — 2006-05-07T21:18:13+00:00

It's been a while since I've posted progress on Headache.

At the last point of contact, I'd created the shell of an editor, however I needed to get the data from C to Python and back again. Python, the language, has a remarkably apt syntax (though some would disagree), however, underneath in the engine room, the code is a nightmare. Creating a usable module for Python in C is a gigantic brainfuck for anything but the simplest of modules.

After a couple of weeks hitting brick walls, I relented and searched for easier options. I found a friend in Pyrex, an intermediate C/Python language that was designed to make modules effortless to write, and it was mature enough for production purposes (though a couple of features were a little undercooked). If you ever need to interface C with Python, Pyrex should be you first port of call.

Now to Headache itself. In a couple of weeks we are releasing an early adopter version of HeadacheTracker (the library will be available for free, always), so musicians can get writing fluid event-based music. In the not too distant future, I'm going to be documenting techniques for writing emotive event-based music. Please note, this is NOT just cross-fading tracks, or muting channels. HeadacheTracker allows the musician to decide how events affect the music they write, but writing an event-based track is different from writing a linear track.

Also note, it is a tracker, not a MIDI sequencer. If there is sufficient demand, we will hack together a MIDI plug-in so musicians can use their expensive rigs to create music. That will require a plug-in structure first, something the early adopter release does not have. The application is bare bones functionality right now - all the goodies will have to wait.

When the library is available, I'll submit a snippet for adding it to Torque. Adding it to any program is dead simple, and we are releasing extensions for our favourite scripting languages as well: Python, Lua, Ruby and Blitz, with Java under consideration.

We are eager to show that you don't need a ten thousand dollar rig to start creating great music. If you're interested in what we're doing, let me know with a comment and e-mail.

Thursday Jul 28 15:43

Paul Malyschko — 2005-07-28T15:43:58+00:00

HeadacheTracker is coming along.

My team and I have been developing an interactive music engine for some time now. After three months of programming in Python, I'm almost ready with editor side of things. It's kludgy, but it works. At the moment I'm having fun deciphering the complex notion of writing Python extensions. It's quite complex, certainly more complex than writing userdata for Lua, though the principles are the same. The backend engine works, the editor works, I'm just working on meshing them together.

Thankfully, Python ports to different platforms without any changes, so long as you don't do bonehead things like code mini frames with their own menus (OSX changes its menu bar depending on which frame is in focus, not a particularly desirable behaviour).

The engine itself is being coded under OSX, so a couple of weeks ago I bought a secondhand 12-inch 500 MHz iBook. It's the ultimate in portability, and I have to admit that ever since I bought it, my PC has been starved for attention. I've never been what you'd call an Apple fan - my friends and I slayed them during high school - but they've really come through with their industrial design. It's certainly better than the luminescent clam shell that came before it.

Here are some screenshots.

Headache under Windows:

Headache under OSX:

(Yes, I'm assuming it works under Linux)

Headache's format can be best described as a mix between an old school tracker and a sequencer. You write channel blocks which you can then place as many times as you like in the order list. You can also write event handlers that will alter the music depending on how it was written. These events are arbitrarily triggered from game code, and you can create and call as many as you like.

Unfortunately, the prototype is a month overdue, which I find irritating. Nothing ever seems to get done at the rate you want it done, but alas, such is the development process.

I'm hoping to begin usability testing on the editor very shortly, and perhaps testing the smoothness of implementing the Headache library within game code, perhaps in an upcoming GID. If there are any musicians interested, e-mail me at paul dot malyschko at gmail dot com, and I'll get back to you.

Cheers,
Paul.

Saturday Apr 23 18:55

Paul Malyschko — 2005-04-23T18:55:09+00:00

It's been a few months since I've posted a .plan, as nothing particularly noteworthy has occured during that time, but today was just so productive that I thought it prudent to record it.

Since September last year, I've been organising a team to begin work on a game I've been designing for about a year or so that forked from an earlier design I wrote up as a teenager. However, for the last three months there's been naught communication, as we've been without an online presence. That has been rectified recently, though we are yet to have a proper meeting to decide some impending issues which will direct the future of the company I am starting very soon.

It all feels so big, but it's cool.

Anyhow, in earlier .plans I've mentioned a music tool we were working on, and after months of research into the best tool for RAD (rapid application development for anyone not in the know), I ultimately settled on wxPython. I had attempted the C++ wxWidgets library, but for some reason found it a pain to get anything done and abandoned it late last year. I also came across a nifty XML-based GUI format called XUL, which works off of the Mozilla platform. Unfortunately, you can't develop standalone applications with it yet, and there seems to be a heap of binding and abstraction of resource files you need to learn to get it all to work. Despite that, XUL (as far as I can tell) was developed by the Mozilla people and has very positive working examples in Firefox and Thunderbird. XUL allows the GUI to be cross platform, and work with very little tweaking, as well as effortlessly allowing cool things like skins to be added.

Yesterday I started researching wxPython to see how easy it *really* was. I already had Python 2.4 installed on my system, so I installed the appropriate wxPython set, loaded up an example I copied off the Wiki and it worked instantly. No endless fucking around to make something work! While not a fan of Python's syntax, it's this smoothness (to hijack Seth Godin's terminology from Unleashing the Ideavirus) that makes programmers want to use Python.

This morning, I prepared myself for a day of more research and programming. I'm a fairly proficient C programmer, but I've never coded anything in Python (I hadn't even completed a tutorial), so I thought I would get nowhere. Not so! By the end of the day I'm about a quarter way to a working application. I have a GUI program that is layed out the way it needs to be, can add lines and delete lines, quit and has it's own about message (which still retains the message I copied from the working examples off of which the program was based). While doing this, I've learned many of Python's nuances, many of which are annoying, but you can't beat it for speed.

I'm anticipating the application will be functional by the end of the week. There will still be some back end stuff that needs working out (the other programmer is working on that), and I need to embed a specialised version of Lua for our macro language, but we could be testing this within the month, something I never thought would be happening.

Screenshots will be coming soon. :)