Some Thoughts on Programming

During my life and career as a programmer, I have gradually adopted a pragmatic attitude towards software projects and my role in them. I expect every assignment to end up being something totally different from what was explained in the originally project specification. Also, at any given moment fundamental conditions for the work may radically change in relation to what they were a month or even week ago, and they may do so many times. This is to be expected of any normal software project.

I believe this because I see it happen constantly in projects I work in, but I have also figured out that there may be a logical reason for it. Here's what I think:

There is a good chance that every software project will contain elements, large or small, that no one has ever done before. Also, there will most likely be elements, large or small, in a software project that you partake in, that you have never done before.

The reason for this is one of the things that sets programming apart from other crafts: duplication. It's popular to compare programming with other vocations, such as architecture/house building. Most of these comparisons fall flat - creating a piece of software has little in common with building a house. You might compare it to the work of machine engineers, since a computer program can be seen as a kind of machine. Writing a program can be compared to making the blueprint for a machine (or collection of several machines working on a conveyor belt), making soda bottles or mowing the lawn.

But where machines need to be set up in a physical location, possibly needing adjustments to the blueprint to adapt to the environment it runs in, a software program lives in the memory of a computer, where it has all it needs, no more tangible than the thoughts in my brain as I am writing this text. And where a machine needs time to be physically set up, connecting parts that have been transported to the location where the machine is assembled, a software program, once written and ready for production, may be installed on a computer in minutes. If it is prepared for its platform, in the blink of an eye.

In a software project, the resulting product (putting aside project plans, minutiae, and other side effects deemed crucial to the workings of a successful project) is some source code that may be used to create a working piece of software on some selected platform. You need to make this source code (actual program code plus configuration data used by the program code) because you can't use existing software to do the task you need accomplished.

This may be because the software you need has been written by someone else, but requiring too high a purchase price - you believe you can create the same software yourself at a lower cost. Or maybe the software exists for Linux, but you are restricted to using Windows computers. Or maybe the software doesn't exist at all. I have personally dealt with mostly the last of these three possibilities. I believe the first one is rare, except for hobbyists, who often don't organise their work into projects.

Unless you're too mean to buy existing software (or, as is sometimes the case, have an irrational fear of using free software), there will be elements in your project that no one has done before, be it conditions of a new platform or a whole new software solution that the world has never seen. Certainly no member of the project has done it before. If they had, they would dig out their old source code, copy it, and then look for something else to do. If the software exists as free, open source software on the web, the software developer may well download and use it despite restrictions put by the employer, maybe changing some labels to disguise the true origin of the code.

The never-heard-of challenges of a new piece of software can often go deep into the low level. Sorting a list is a classical problem in computer sience, with many established solutions for different situations, but this project might need to sort a huge matrix with respect to other structures on some ad hoc-basis, without needing an aeon to complete. The developer needs to think up a solution for this with little help from the giants whose shoulders he thought he was standing on.

The current trend of development systems with short intervals between status updates, team programming etc may be well suited for handling this issue concerning the unknown that is inherent in all software development. I still feel that we could be humbler and more accepting towards the fact that we don't always know quite what we are doing, in life as in programming.

The 140 BPM Blues

The seasonal streaming event that used to take place every new year's eve at electro-music.com seems to have expanded into celebrating all turning points in our planet's position in relation to the sun. It started with the summer solstice event last year, and now we've just gone full circle - the Spring Equinox shoutcast event took place on the night that was 2010-03-20 - 2010-03-21, with 16 hours of great, disparate performances spread out over the globe. Check them out here: http://electro-music.com/forum/viewtopic.php?t=40217

I played a half hour set titled "The 140 BPM Blues", trying out some clip switching, looping and vocoding. And blues. Here it is.

VG-99

Got a VG-99 and a GK-3 the other day. Acronymn fun! Anyway, here's an image of a GK-3 mounted on a guitar:



That's not my cheap Squier strat, but you get the idea. The deal with the pickup that is wired to the control unit at the bottom here, is that it treats each string separately, sending six individual signals to the control unit and into a 13-pin connector. You can use a suitable cable to connect these 13 pins to an identical socket on a VG-99, which is capable of doing stuff with these signals that you may not have thought possible before.



That's the VG-99. What it does is take each signal and treat it, playing sounds based on Physical Modeling in one way or another, or detecting the pitch of each string and sending it as MIDI note data to whatever synthesizer you'd like. The models include a variety of electric and acoustic guitars, basses, banjos and sitars, and never-before-heard-of synthesizers. These synths don't work like a keyboard-triggered kind, they rather are excited in ways similar to the aforementioned guitar models, creating new kinds of sounds that I (in my admittedly G.A.S-enhanced excitement for a new piece of kit) am very excited about. Here is a test run I did with some synth sounds:

Knotwork

I've posted about this here and here.

It will be fun to see if this leads anywhere :)

Antimon On the "Air"

Wow, apparently I used to post to a blog here once! A lot of stuff has happened - I'm hanging out at electro-music.com, and I've participated in a couple of events, the most recent being streaming events on the summer solstice, the autumnal equinox, new year's eve, and "A Winter's Dream - an Evening of Ambient Music 2" a couple of weeks ago. The last event was the first where I felt I didn't lose track of what I was doing at some point in the performance. Fun!

Next up is a radio show that's sent on shoutcast at radio.electro-music.com. I'm calling it The Antimon Plays Some Doodles Show, and I'm going to be playing all tracks from an album called Doodles, that I've put up on Tunecore, which distributes stuff like this to online music stores, most notably iTunes. I did it mostly to get a kick out of seeing myself on iTunes I guess.