Blog Post

Audio Developer Diary – Episode 5 – Soul of a New Machine

So this week will have to be quick – ’cause I’m mad-busy.

I wanted to talk about all the stuff round the outside of what we think of as “the product” that actually in the end contributes heavily to its definition, or its (cough) “soul”.

We think of the sounds you can make with a VST or AU (effect or instrument) as the defining thing about it, and sure that’s what we buy but there’s a bunch of other stuff, some of which I’ve alluded to here, that makes it a worthwhile experience. I’m sure you can think of some, support for instance readily comes to mind. If a company puts out a product but wont address bugs or help users with complex or difficult install or usability issues then the value of said product falls – sometimes drastically.

But leaving aside the obvious for a minute these a whole bunch of other stuff: the aforementioned installer for instance. Products often need easy to use installers for each of the platforms they run on, so usually at least Mac and Windows – so that’s two more programs to write. Mentioning MacOS then these days these a whole set of hoops Apple require developers to jump through to get a product that will even open or run on your shiney new Mac-machine. We have to Code-Sign all the software and Noterize anything that runs stand-alone (so that means the installer too) – I dont want to get too far into the technical how-tos here but it means joining(and paying for) the Apple developer program and communicating in a very very specific way with the Apple servers – and Apple have been known to change the rules with very very little notice. It’s a pain, but it makes the user experience day-1 much better, so we do it.

There’s a bunch of stuff inside the program itself that is required too. These days many users want a LOT of presets – so these get to be really important – that they sound good, and that the user can find what they are looking for easily and can add and subtract presets in easy and intuitive ways.

Which brings me to the preset browser in Quattro. As I may have mentioned I wanted Quattro to be an extensible platform for content (sounds) – so I envisage adding tens or even hundreds of “extension packs” that the user can buy and install (theres that installer again) at any time they wish.

So that means there may well be hundreds if not many thousand presets available to the user, how to manage this finding and managing? A tag based system seemed easily the best option – so that’s what I’ve built – but not just any old tag based system…

First off I hate tag based systems where I choose a category(over on the left in the image above) and it shows me a set of tags – not all of which result in finding at least one preset. If I select a tag called: “Bonkers” then I expect to see at least one preset that is tagged in that way, sure if I select “Bonkers” and “Sleepy” then there may be no results – that’s fine, but why show me a tag if the program already knows there are no presets tagged with it? It’s these little things that bug me – so the thing above doesn’t mess you around like that.

Also why have a tag based system if the tags are just fixed, I cant add to them (with my own unique “Hull-based humour”) or remove them if I think they are just plain wrong? Again – the preset browser above lets you add tags to existing presets, and remove them. Of course it lets you add new presets, overwrite(save) presets, and delete presets.

What about if you get some massive long list of presets, but you sorta remember the name you were looking for included “Bonk” in it’s name somewhere – again a search filter for the returned results. Finally the ability to just page through all the search results trying them out (those little fwd/back arrows next to the name in blue….

All of these with variable amounts of presets in variable amounts of expansion packs – including no expansion packs at all…

It’s taken months of effort to get it where it is, and all so the machine has a really nice “soul”….

Related Posts