Blog Post

Audio Developer Diary – Episode 1 – Patience Grasshopper…

(OK so even before we begin, an admission – just like the last time I did this I am already well on the way with development of the plug-in I will be talking about, so (again) I’m having to back track a bit to cover the start-up phase of this development, but anyway: QUATTRO…..)

Over the last couple of years I’ve built a whole swag of plug-ins for myself and for other people – about 25 of them, and whilst there were unique ones most were “ROMpler-style” products, and unsurprisingly there was also a huge chunk of functionality that was very similar in each: voice selection, filters, effects, envelopes etc. etc. So for myself I wanted to build a one-product-to-rule-them-all type thing, a “player”, where I could enhance and improve it over time – never having to go back to the base metal.

But that meant being able to install a plug-in and then add to it with expansions, only updating the plug-in itself when I had new functionality – and allowing users to mix-and-match which sound sets they wanted to use, yeah like Nexus – but with deep(er) editing…. So this expansion capability was “coming soon” to HISE (the product I mostly use to build things) but at the start of all this it wasn’t here yet. So just like users the developer community sometimes has to have a fair degree of patience waiting for a feature they want to be added to be underlying building blocks of their product set. So I waited and tried not to get “naggy” about it.

The nice thing about waiting for a thing is you get to have some thinking space, so that’s what I did; a bit of thinking.

So to stretch this Kung-fu TV series analogy even further… if you’ve seen it then there’s bits where “grasshopper” has to learn how to walk on rice paper without leaving a mark – and that requires considerable restraint and balance, and I realised that was something I was going to need too…

Building a massively powerful engine with tons and tons of capability is all well and good but I’d come to learn that what most users really-really want is a simple and intuitive interface that’s quick and easy to use. These two things don’t fit together easily. So there are two classic solutions to this dilemma:

  1. Hide it all for ever – give the user a set of simple interface controls and make these work on a whole range of features under the covers where the user never sees them.
  2. Hide them – until they ask for them. Put the controls for all this cool new functionality in a separate part of the interface and only go there when the user asks for it.

Option 1. is great – but gets hairy the more features you add, and can get counter-intuitive. Having one dial that controls (say) all the time related stuff makes perhaps some sense for modulator speeds, but delay times too? Yeah its messy quickly. Added to that was I wasn’t sure what all the functionality would eventually be – and adding stuff that broke the “paradigm” would be deeply frustrating to the end-user, not to mention all the undefined and yet to be thought up content that might end up in here

Option 2. This let me set up some overarching simple UI that would get a lot of good stuff done quickly and then to offer users an “Editor” page where they can dig deep and get to all the really cool stuff.

So I went with option 2 – good job – ’cause there was a truck load of functionality coming down the pipe….

Related Posts