The impact of technology on music


Spongefork was great fun, I hope Ryan reups it like he says he’s considering…

And Argeiphontes Lyre was a gateway drug for sure!


Oh my, Lyre is on the apple App Store!! Like @eblomquist it was a gateway drug for me as well back in the days. I remember toying with Spongefork some, but @dailybells’ post is making me want to revisit it.

I’m with you most of the way. The ongoing dominance of skeuomorphism in mass market music software is in many ways a hinderance to breakthroughs in UI function.

Some points to consider.

1. User knowledge vs function.

  • Take your example of linear timelines in DAWs. Breaking with that paradigm comes at a cost in terms of learning curve for users. Ableton’s clip view is a great example of an alternative that hit a sweet spot in terms of the benefits of new functionality vs cost of learning curve for countless users. So it spread. Just as importantly, linear DAW timeline themselves arguably also hit a sweet spot in terms of functionality benefits/downsides and learning curve for countless users (and use cases). So they spread and are sticking around.
  • Take your example of VCV Rack. There, the balance achieved is quite different. Crudely, I take it that the background assumptions were: (a.) there’s valuable function to hardware rack modulars; (b.) there’s a high learning curve to (a); (c.) given the cost of hardware modular, access to free/dirt cheap software where the user knowledge is directly applicable to hardware modular and vice versa, and that approximates (a.) as closely as possible, will be hitting a sweet spot for many users. Arguably, the proof that they did hit a sweet spot is in the pudding…

2. Skeuomorphism as resource (vs as dogma)

  • Take your example of Bitwig. It’s striking that Bitwig’s first step in implementing modular modulation functionality wasn’t skeuomorphic: IMO the layout and visual language of the modulators from 2.0 onward is distinctly software + GUI centric. I’m not saying that nothing in pre 3.0 Bitwig was skeuomorphic. But I’d argue that their approach overall has been a good example of using skeuomorphism as a resource. I’m with you in opposing skeuomorphism as dogma. But why should good design deny itself that resource when and because it serves the target function and usability well? Looking at the snippets we have of 3.0, what’s striking to me is how close the grid ends up remaining to the visual language Bitwig has had all along - or conversely, how sparse the skeuomorphic additions end up being. I don’t know enough about BW3 to judge, but I’m guessing I’ll end up on the side of thinking it’s yet another example of good use of skeuomorphic cues as a resource - not as dogma.
  • Another example I like a lot of skeuomorphism as resource, and decidedly not dogma, is Madrona Labs/Randy Jones’ patcher-in-the-middle format for his synths so far. The “cables” are pretty much the only skeuomorphic thing on there…


Hear hear! …


Not meaning to disparage these tools! I’ve watched a friend prototype his new module with its VCV rack doppelganger and talk about a fantastic platform for doing that – he can simulate ganging up a whole rack of 10 of them, or try out some new UI affordance while waiting for new hardware to arrive from a manufacturer etc. I totally agree it has its place.

Bitwig also seems awesome but if go to their website right now I see pictures of knobs as interface controls. Unless your goal is to emulate some existing hardware directly, like VCV rack, I can’t think of a single reason to use a knob interface with a mouse controller or touch interface in software. The patch cable skeumorph can work in areas of low complexity – and be clearer to read than alternatives – but as anyone who has done extensive patching in a system like PD etc can attest, there reaches a point where you have to fight the interface just to see through your piles of virtual patches. Often these insane spaghetti patches can be represented in text form as few lines of readable code. Just as you’ll have situations where something that’s relatively simple to patch together might be very difficult to represent clearly in some text-based environment. IMHO although these translations of physical interfaces to software UIs might be familiar and make initial on-boarding to some environment easier, they moreso create a barrier and obstacles down the road.


They are slightly more compact than faders but in general I agree.

As a coder I agree with this, but coding in text is extremely unfamiliar interface for most (albeit diminishing in proportion) humans.

Often by the time you’ve progressed that far down the road you have changed in terms of your requirements and/or capabilities. Often this is when folks are ready to change modalities (gui to text) or metaphors (skeumorphism to something more direct but abstract).


Hopefully my rants are coming off in the spirit of hopefulness & utopian dreaming for future musical tools… but I’ll be contrarian again here just a moment because I think this is a good illustration of it all. Rather than knob VS fader, with the potentially arbitrary visual interface that a screen affords which can recompose itself at will, the interface could simply be a number which is the current value for the control (maybe even with a small line beneath as a visual aid for position within the control’s range) which when clicked can be edited by typing precise values with a keyboard while at the same time bringing up a large slider / fader UI as an alternative input that works fine with a mouse or touchscreen. Just for example. Maybe the fader is a freeform canvas and the number is a color representing average intensity of the spectrum of the canvas when read as a wavetable, etc etc.

Coming back to the subject of the impact of this stuff on music – these interfaces can help or hinder just as easily the musical process but they absolutely will shape the experience in some way. As a way of visually thinking through sound they might be a huge crutch or inspire new ideas. The interactive and self-recomposing nature of screen interfaces allow much more to happen than just simulate potentially expensive or difficult to manage hardware equivalents (though they can do this pretty well too of course) but sticking with these paradigms imho just creates limitations where they aren’t necessary.

This makes me think of the interview I just watched with Beatriz Ferreyra where she talks about her students becoming totally lost during listening when they can’t look at a timeline or some visual representation of the sound. And probably why so many folks I know make a habit of turning away from the screen while listening – maybe this is also partly the attraction of working with devices without screens as well. It certainly has an impact on your listening!


I think having the interface for parameters be merely numbers, while sensible, runs the risk of “sterilizing” the instrument; tweaking such a parameter (in my experience) leads to focusing on dialing in an appealing number, rather than picking a good spot within a range. Music making is not a science; it often doesn’t matter if your parameter value is 27.485 vs 28. A knob or a fader does a good job of hiding or mitigating these irrelevant technicalities, even if interacting with them via a mouse feels strange.


20 characters of this


Aren’t there more graphical possibilities there than just knobs and faders given a freeform canvas?

For example the interface for DIN which imho uses numbers, lines, buttons, etc in a way that doesn’t try to be anything except an interface for the given task:


For sure. And DIN does seem inspiring.

But it depends on if you’re making something bespoke for yourself, or making something intended to be used by a large number of people, or making something intended to be used by the largest number of people possible. Depending on which of those three categories you’re aiming for, you’re going to have very different values for “current knowledge” among your users.

Jared Spool has this to say:

Current knowledge is the knowledge the user has when they approach the design. It’s the sum of all their previous experiences with relevant products and designs.

Often we use less imaginative interfaces, because we are attempting to leverage a user’s current knowledge.


It does evoke trackers, though - which is pleasantly nostalgic…


Absolutely. And also why in a lot of my design work over the years we’ve tended towards a really thoughtful approach to deciding when to use familiar interface tropes, and when to invent something new or subvert expectations intentionally.

If you change everything, and people come in with no existing knowledge to bring to the interface it can be daunting, confusing, and you’re asking them to invest a lot in learning the new paradigms. If you make things familiar where they don’t need to be new, but introduce new things for specific reasons (effect, utility, emotion, etc) then those things stand out, and people will learn them one thing at a time while still feeling comfortable/safe to experient because of the familiar environment.

Edit to add: This is why research into your target audience is so important. If you know what people will bring to your interface you can use those familiar tropes in smart ways. So if you are making something for people who have used Trackers, you can pull from that. For others it may all be new, but maybe they’re not the majority of target people…


All makes sense! I’m thinking in terms of instrument design I guess rather than product design, but I suppose that line has been blurred very much when it comes to new (especially electronic) musical instruments…


I am very grateful for the twin phemonena of DIY/maker culture and open source, for opening the door to a thousand flowers blooming in terms of bespoke design that has no reason to constrain itself to the current knowledge of large masses of people. It’s a gorgeous outpouring of creativity and innovation. And once in a while (monome grids, are an excellent example) some of these ideas come out of left field to become mainstream.


As soon as you’re talking software/hardware with lots of controls and feedback cycles it’s all interface design. Instruments just imply different paradigms, uses, and ways of learning.


Excuse my ignorance but why does 20 characters reference keep appearing as a thing in posts?


Because the forum software won’t allow us to make posts of fewer than 20 characters.

There is a hack though. Just keep pressing the period key … and the software will accept them as characters, but visually reduce them to a single ellipsis.


I suppose the difference I see between the two is that when designing an instrument, a steep learning curve isn’t a problem if it is in service of affordances of playability etc, while in product design as has been mentioned you might need to care much more about things like borrowing from familiar interfaces etc…


aha, thanks Jason…


I see musical instruments (such as traditional orchestral or band instruments) as falling into the second category of the three I mentioned. Used by large numbers of people with specialized knowledge, but not by the masses.

And it’s a fair point that this is probably a wiser target than “everybody who owns a computer” or some such, and does suggest that perhaps we could get away with a little more imagination in electronic musical instrument interface design. We’ve mentioned a whole bunch of examples of people doing just that in this thread. Would be interesting to see larger software and hardware manufacturers getting similarly adventurous. But they’re going to want to protect their investment by starting with a solid foundation of user research, I would suggest.