Music Software & Interface Design: Propellerhead’s Reason


I discovered Reason when I was in my early
20’s. It was great. Even though at first glance it looked a daunting hellscape of never
ending, incomprehensible controls, [Scrolling down the app] – ‘What the hell – flipping
it around… AHhhhh?’ it’s actually really intuitive: you drag audio units into a virtual
rack, you wire them together and hey presto! you now have the ability to construct incredibly
powerful synthesisers from the ground up. And it all works in real time, which allowed
the band I used to play in, [2wenty 2wo CD cover] to create our own sounds and use them
live without having to pay a fortune for high end hardware. However, in the mid 2000’s due to increasing
competition, technical growing pains and the some notably absent features, Reason began
to feel a little bit inferior. And noticing this, Propellerhead [VISUAL – the makers of
Reason] realised they needed to make some dangerous design decisions in order to get
Reason to be the all singing, all dancing Audio Workstation everyone wanted it to be.
Many people, myself included, were skeptical they could pull it off – and yet somehow,
they did. And in this video we’re going to look at that journey because it offers
a masterclass in design decision making. From high level strategic decisions, down to the
minute detail of how the interface of Reason looks and feels. Things other companies would
do well to take note of. And this is the first in a series that will touch on different audio
applications from a musical and design perspective. I’ll talk more about what’s next at the
end. In 2005, I moved to London to study music
composition and funding myself by working as a software designer. And from these two
new perspectives, I began to look at Reason in a different way. As a composer, I wanted
it to be a full blown digital audio workstation (or DAW), with audio recording and professional
mixing. But as a designer, I recognised that this wasn’t a simple thing to just go and
do. To grant this request, some very difficult design challenges needed to be overcome, which
we’re going to look at through a very specific lens: something that’s rarely discussed
in software design that I think needs to be called out more often: design idealism. — This is a blanket term I’m using for the
practice of strictly adhering to self-imposed design rules. The ideal is that by choosing
a perfect vision, you can get close to achieving a ‘perfect’ application. Something immensely
satisfying that requires zero learning curve to use. And even though we all know perfection
isn’t possible, it makes sense to try to achieve it – which is why when companies are
faced with unexpected roadblocks, there’s often an instinctive emotional reluctance
to deviate from the established vision. Because – if perfection is no longer the goal, then
surely we’re moving in the wrong direction, right? And when I say ‘design rules’ I’m referring
to everything: High-level strategic decisions, like defining your target audience. Company
matras stating broad principles like ‘We do it Differently’ or ‘Democratising ‘XYZ’
for Everyone’. Then t here are mid-level design rules that state how your software
is generally arranged all the way down to tiny visual rules dictating things like the
precise amount of pixels between controls. And you can add into the mix, a range external
design trends and ‘best practices’ which can also be quite influential. These also
serve a practical purpose: helping to set a common vision for designers, CEO’s and
investors alike, while avoiding the organisational chaos that can occur when people go off and
do their own thing. And as you probably guessed, this video is about the difficult moments
where you need to break these rules. Where you should be non-ideological. Simple in theory
but often fiendishly difficult in practice. Let’s start with a simple, small-scale example
of a general trend. If you work in design, you’ve most likely come across ‘Click
Counting’: the practise of setting a limit on the number of clicks (or presses) [Show
mobile phone / tablet] it takes to get from one place to another. The phrase ‘No more
than three clicks away’ is pretty common in the world of design and although the intention
is good, it nearly always results in up front clutter, like this: Ah! What am I looking at? There’s options
for my options! Home, My Page, Menu…
AhhhhHH! For sites like Amazon [1-click shopping visual],
this type of principle makes a lot of sense but in other cases, it doesn’t make sense.
So let’s apply it to something generally regarded as well designed, like the iphone
menu, we’d get in trouble pretty quickly. If I want to change some accessibility settings,
say. 1, 2, 3, uh oh, 3 clicks rule says this isn’t good design. We need all those options
in one gargantuan scrolling list. I hope your accessibility issue wasn’t carpal tunnel
syndrome! (Ahhhh) Another ideal designers worry about on a daily
basis is ‘consistency’. Obviously if an app behaves in a consistent way, then it’s
going to be easier for people to navigate it without getting confused. Imagine you were
making a website that used the colour Red to mean ‘No’ and green to mean ‘Yes’,
then it would be a pretty big mistake if your credit card details page that was styled like
this: [a visual with a ‘Red’ submit button above a green ‘Clear everything & start
again’ button]. However, at the structural level, the topic
of consistency gets a bit more complicated. Back to my earlier example of wanting to find
things quickly on the iphone – Apple eventually realised that their menu was slightly clunky
when it came to common tasks like turning on and off WiFi. And because they didn’t
want to break with the perfectly good system they’d already built, they instead took
a lesson from Android and Ubuntu Mobile by introducing the Control Centre with IOS 7:
a necessary half-way house that broke with both the look and logic of the rest of the
system. Usability before consistency. Good Apple. You get one point for that. And with this in mind, we can now start talking
about the massive design problems faced by Propellerhead. By the time we got to Reason
5, it had two major consistency rules – first: anything that produced sound was represented
as a physical pieces of hardware. This real-world representation made it easy to ‘get’ how
Reason worked. But this came with limitations: mimicking the real world in this way requires
that you observe the rules of physics – especially the idea that everything had to wired up in
order to work. So if I wanted to do something complex, like send an audio signal to multiple
different places, I’d have to first send it to this – a unique device that splits the
signal, giving me multiple outputs – each of which I then have to wire to the intended
device manually. Programs like Logic Pro use a more abstract system where you can send
an audio signal to multiple different places by selecting them from a disconnected dropdown.
The link between elements is implied – more in line with other musical creation apps.
And although this is faster, it’s not necessarily better. Apps that rely too much on abstract
connections can be difficult to learn, which can dissuade first time users from ever coming
back. So even though Reason’s literal system was sometimes clunky, it was easy to understand
and also kind of fun too. The other major consistency rule of Reason
was that all sound had to be triggered by midi, either written in manually [Visual of
piano roll] or recorded externally on a keyboard. If you wanted to use pre-recorded audio of
any kind, you had to import it into a sampler and then trigger it using a midi signal. You
couldn’t just record audio directly into Reason because… that wasn’t really what
it was originally built for. This meant that the controls for Reason were streamlined.
Everything worked the same way. But as programs like Cubase, Logic Pro and
FL Studio introduced features that directly competed with Reason, they began looking like
the better overall choice – great synths and the ability to record and mix live audio.
And there was definitely a point around 2005, where Reason looked in danger of becoming
obsolete. And so, Propellerhead began planning to offer
audio recording and proper mixing functionality. And here’s where they came up against a
giant design challenge. In order to offer any of this stuff, they needed to break not
one, but both of their core consistency rules. Let me explain. Up to Reason version 5 – you
first created your instrument and then hooked it up to a main mixer at the top of the rack.
If you didn’t do this, you didn’t hear anything. And since each mixer contained only
14 channels, you often needed to awkwardly chain multiple mixers together to get more
than that. This is why audio recording posed such a large
structural problem. Imagine how bad it would be if every time you wanted to record a new
take you had to manually wire the channel to a mixer? It would never fly. Audio recording
needed to be automatic and far more channels were needed too. And as I mentioned earlier, the danger in
breaking with these established rules is the potential it has to alienate existing users
while steepening the learning curve for newcomers. But regardless, Propellerhead took the brave
decision to make big changes that created multiple inconsistencies. First, they introduced
a virtual mixer that lived outside of the rack and which had no visible connection to
the devices. This meant that when you created a new audio track, it was represented by this
piece of imaginary hardware, which just popped into existence. It wasn’t wired in any visible
way back to the main mixer. You just had to learn that for every one of these you had
in your rack, a channel existed for it somewhere in your mixer. And by allowing audio to be recorded and played
back independant of midi, a whole bunch of new interface controls were needed, which
took away from the apps simplicity. This can’t have been an easy decision for Propellerhead
– breaking with the traditions that had put it on the map. And I’d love to know how
many arguments it caused in the design studio. But I think it was the right decision. Rather
than sticking to an ideal, they risked complicating their existing system and forged ahead – making
sure that everything new they created was as fun and ‘Reason like’ as possible.
The result is an app that’s infinitely better than before – albeit, with a slightly higher
learning curve. So now, let’s take a look at Reason from
a slightly different point of view. One of the problems of interface design is that things
go in and out of fashion relatively quickly and when journalists write about specific
examples of ‘bad practice’, say in web design, it can gain traction, often influencing
designers working on something completely different, like a game or operating system.
For example, I can’t count the amount of times I’ve seen mobile app controls ending
up on the desktop. Oh look! Pitchfork have this hamburger menu now… um, my whole screen
is taken over… so I can see the same options I have here…you ever heard of a rollover?
Oh Pitchfork. The best place to go for all the latest showbiz goss… “Ariana Grande
taps Nicki Minaj for New Song ‘The Light is Coming’ colon listen”. Cool! Oh look!
Pharell – dat’s tree names I know! So as an example, let’s look at an article
that came out in August 2017 titled ‘Why are there so many knobs in Garage Band?’
– which criticises a variety of music creation apps for their heavy use of something called
Skeuomorphism. For those who don’t know, Skeuomorphism is a tedious design buzzword
that refers to the practice of basing interactive elements on real physical objects, like a
slider which mimics the way a slider works, or… I know there’s another example…
it’s pretty common…what are they again?… oh yeah.. BUTTONS. And one thing to note about
skeuomorphic design is that just because it works like a real thing doesn’t mean it
has to it look like a real thing. [Example of abstract button] Skeuomorphism can be observed in the older
versions of Apple’s IOS (for some reason, the iphone just keeps popping up in this video).
For example iBooks used to look like an actual bookshelf until a few versions later when
Apple finally realised that it was pointless and awful looking. And due to the large amount
of commentary on this topic, skeuomorphism became a bit of a dirty word. Bad Apple. That’s
-1 point for you. And if we scroll down through the article
– past some admittedly bizarre looking plugins, [Waves Plugin] I mean – what a flagrantly
inefficient use of space – oh look! A little section on Reason! “…a digital audio workstation designed
to mimic the flexibility of a studio rack full of analog equipment. Unfortunately, it
also mimics the look of such a rack” …and why is that bad? Oh, that’s it? It’s
bad because skeuomorphism is bad. End of critique. I guess it’s just lost on the author that
one of the advantages of designing an interface in this way is that it helps complicated things
to be separated out into visually distinguishable parts. Or that the mimicking of real world
analog devices is very useful for young musicians because it actually teaches them about how
these things work in real life? But hold on, there’s more insight to be had! “It also features circular rotating knobs,
surely the most pervasive/least useful UI element in this type of software” What!? OK, let’s just put that statement
to the test. So in music software, knobs work like this: you click and drag upwards or downwards
to change the value. And most commonly if you hold shift, then the control is much finer
so you can hit precise values. In other apps, like After Effects or Premiere, you can drag
on these text values in exactly the same way. This is about as efficient as it gets and
knobs are just a different looking version of the same thing. But [Girl Headphones] you
might rightly ask, ‘can’t we just show text values instead of knobs then?’. Well,
let’s take a look: here’s a synth in Reason that has loads of knobs. But what if we replace
them with text values instead. Hmm. OK – so first off… unlike knobs, I have no idea
of what the maximum or minimum of any of these values are – meaning I’ve lost information.
And I can no longer quickly glance at any area to get a rough idea of how it’s arranged
– I have to read each value one by one to comprehend it. This is compounded by the fact
that midi parameters often range from -64 to 63, meaning that I’ve no common baseline:
‘0’ could mean either ‘nothing at all’ or ‘right in the middle’. Not to mention,
if I have an external keyboard and I turn one real knob, I can no longer see its equivalent
turning in the UI. So figuring out how things are connected is much more time consuming
too. Yep. You see why they chose knobs? ‘surely the most pervasive/least useful UI element…’
Yeah. Good work, I’m giving this article an E-. Congratulations! You didn’t get an
F. I gave you credit for not mentioning Hitler. Round of applause everyone! This is the sort
of criticism Reason has faced for years. A criticism they have rightly ignored because
they understand better than most the value of their unique mechanics. And one last point about this – if you think
these controls look a bit lame and you’d like to see something more modern, like the
Yofiel Synth seen here, then fine. But don’t make the mistake of assuming that just because
they look cheesy that they’re bad from an interaction point of view. Elements like this
are only bad when they’re being misused. If my dog gets sick and I choose to cure him
with a spanner, his death isn’t the fault of the spanner…. it’s his own god damn
fault for getting sick. Anyway the most recent improvement Propellerhead
made marks yet another big reversal for them – finally providing VST plugin support – something
they’d said they’d never do in the past – so much so that when their CEO made the
announcement he started with the words ‘When hell freezes over’. Instead of persisting
with the argument that VST’s reduce stability and performance, they instead allowed us to
decide on that trade-off for ourselves – and as a result gave us a massively improved range
of choice, allowing me to finally use my favourite synth of all time. (Serum) So before I talk about what software I’m
going to be looking at next, let’s give one last hurrah for Propellerhead for their
practical design decision making, both small and large-scale. They’ve had some bumps
along the way [Record visual] – but they’ve always rebounded to make the right choices
in the right order. Well done propellerhead, you get a point. And if you wouldn’t mind,
I’d also love a point. So what’s next? What other music software app can we look
at that can offer us unique insight… [SIBELIUS icon – horror music] Oh… SIBELIUS icon – Larger OH! [SIBELIUS – LARGEST] OH… JESUS… JESUS CHRIST!!!

Leave a Reply

Your email address will not be published. Required fields are marked *