Ardour 9 was released recently and I think you should take a look at it.

[ampetrosillo]

Gnome’s vision might be neat on paper, but forcing users to follow it is not UX, it’s arrogance. I don’t need your ideology, I need software that works for me.

It's not all about ideology. If you're talking about consistent UX, you also want to enforce it. Also, the user is expected to conform somewhat anyway. Whenever I use an iPhone, I feel completely lost because a large part of the stuff I want to do is either impossible or different. So I have to learn to use it. Since I don't own an iPhone nor do I intend to, then I feel challenged whenever I have to use one.

[Tiles]

The Linux world rarely lives on the desktop. Most stuff is (still) done in the terminal, for better and for worse. When it comes to desktop Linux, you have to start specifying which one of the dozens of DEs you are referring to. Is it Gnome? Is it KDE? Which implementation?

It does not play any role which disribution or desktop you pick. They all have pretty equal trouble points. And when we talk about desktop software like Ardour then we also talk about a desktop OS. Not about servers. That's pretty off topic.

But you're seeing it from a very Windows-centric point of view. Linux people could say the same about Windows when it comes to a large number of Unix-isms that Windows sometimes goes out of its way to impede.

Framing me as a Windows fanatic seems misleading. My point comes from my experience as a UI/UX design expert, a long-time developer, and both a Windows and Linux user.

Written from Ubuntu at my dual boot system

It's not all about ideology. If you're talking about consistent UX, you also want to enforce it. Also, the user is expected to conform somewhat anyway. Whenever I use an iPhone, I feel completely lost because a large part of the stuff I want to do is either impossible or different. So I have to learn to use it. Since I don't own an iPhone nor do I intend to, then I feel challenged whenever I have to use one.

And here we come full circle.

What you are describing is exactly a core UX issue: consistency and predictability. Good interface design is not just about making things look nice, it is about creating a system where users can apply what they already know to accomplish new tasks. When a system behaves differently from what the user expects, every action becomes a mini learning process. That is why using an iPhone can feel disorienting if you are used to another ecosystem, the interaction patterns, gestures and workflows are all optimized for a certain usage model, not for transferring skills from other platforms.

UX design aims to minimize that friction. Ideally, interfaces should guide users intuitively and support the user’s mental model rather than force them to adapt to arbitrary rules. When consistency is missing, even simple tasks can feel confusing, which is exactly the friction you experience.

[jens]

what is the current status on ARA support?

I read through a thread in the Ardour-forum a while ago where you devs (i.e. Paul and a second one) appeared - frankly put - rather ignorant on what ARA actually does/what advantage(s) it offers...

[ampetrosillo]

If you have a look at Apple's or Google's design guidelines for apps, you'll see that they clearly point to a set number of ways to do certain things (with Apple usually enforcing *one* and Google allowing a couple of variations). Their UI libraries do not even allow, in some instances, to do things differently. They are the product of UX designers identifying user behaviour or imagining future behaviour patterns.and regulating app development consequently. If you want to do an Apple-ism on Android, you usually can (and it will often look weird). If you want to the other way round, you usually can't (and if you can, you will probably get your app rejected by the App Store). Both companies spend a lot of money and energy into their UI and UX, and they can't be said not to be UX-driven. Apple can't be said to be inconsistent, on the contrary.

But UX design, for starters, is a very recent development, and it is at a relatively primitive stage really. UX design is often just the vision of the lead UX designer, and it is not "scientific" in any way, shape or form. UX design should probably be "design apps as to be logical and natural for even completely virgin users to use", but in practice is either "design apps so that they work *this* way, so the user knows what to expect", or "so they conform to common usage patterns borne out of previous commonly used designs". Gnome happens to espouse the first idea of UX (most of their decisions tend to be dictated by academic studies). Apple subscribes to the second, even going to lengths such as "throw out everything that does not match in lockstep with our decisions". Google and Microsoft the third (sort of). Each for a reason (Apple being isolationist and very top-heavy; Microsoft trying to be all things to all people, and keep them in for perpetuity; Linux being in the position to experiment).

Often, UX design is just a form of branding. "Do things our way".

Gnome also has design guidelines. But Gnome is not in a position to enforce anything, because on Linux, you can deal with maybe half a dozen UI libraries daily (with the two biggest being Qt and GTK, both in at least two or three different versions).

[Tiles]

Often, UX design is just a form of branding. "Do things our way".

Plain and simple: then they do it wrong. That's exactly what I moan about. Exceptions must always have a reason.

Apple and Google invest heavily in UX and enforce consistency through their platforms. Apple is highly prescriptive, with guidelines effectively enforced by the App Store. Google allows more flexibility but still constrains behavior through Material Design. Both approaches are clearly UX-driven.

Yet UX design and implementation are entirely different things. Many open source projects, even with solid design guidelines, struggle in execution because of fragmented toolkits, multiple versions, and volunteer-based development. GNOME, in particular, struggles not just with implementation but with the guidelines themselves. They often create rules that contradict each other, leave major gaps, or are ignored entirely. Without enforcement, this leads to a constantly shifting UX where yesterday’s principle can be abandoned today. This is why open source consistently loses out compared to controlled ecosystems like iOS or Android: good design can be rendered meaningless by inconsistent or incomplete execution.

UX is never just about following rules. Context matters. What works on a desktop may make no sense on a smartphone, where desktop-style shortcuts often become irrelevant. Effective UX always requires considering the actual use case and environment, not just adhering to guidelines.

Much of UX is still heuristic, shaped by lead designers rather than a fully scientific approach. Apple follows top-down patterns; GNOME aspires to logically consistent, user-focused design but too often fails in practice; Microsoft and Google prioritize flexibility and familiarity. Each reflects organizational priorities more than objective UX science.

Unfortunately, there is so much to consider in UX design, but 25 years of experience cannot be compressed into two sentences. If it could, this discussion would look very different. Not that i did not try, my last attempt endet in a book with 400 pages. And especially the experience when to use what rule is hard to teach.

[dawhead]

what is the current status on ARA support?

I read through a thread in the Ardour-forum a while ago where you devs (i.e. Paul and a second one) appeared - frankly put - rather ignorant on what ARA actually does/what advantage(s) it offers...

Robin and I spent some time last year looking at ARA. It is is INCREDIBLY complicated to implement, and to do it properly requires providing new thread and buffer designs. It's not that it is badly designed - most of the reasons it is why it is seem relatively obvious and well-founded. But it will/would be a huge amount of work and so, despite being urged on by some folks up the Harrison ownership chain, we decided to defer it for now.

We would like the integration with melodyne (and maybe, what, 2 or 3 other plugins?) but the bang-for-the-buck just doesn't seem worth it right now.

[ampetrosillo]

Often, UX design is just a form of branding. "Do things our way".

Plain and simple: then they do it wrong. That's exactly what I moan about. Exceptions must always have a reason.

Apple and Google invest heavily in UX and enforce consistency through their platforms. Apple is highly prescriptive, with guidelines effectively enforced by the App Store. Google allows more flexibility but still constrains behavior through Material Design. Both approaches are clearly UX-driven.

Yet UX design and implementation are entirely different things. Many open source projects, even with solid design guidelines, struggle in execution because of fragmented toolkits, multiple versions, and volunteer-based development. GNOME, in particular, struggles not just with implementation but with the guidelines themselves. They often create rules that contradict each other, leave major gaps, or are ignored entirely. Without enforcement, this leads to a constantly shifting UX where yesterday’s principle can be abandoned today. This is why open source consistently loses out compared to controlled ecosystems like iOS or Android: good design can be rendered meaningless by inconsistent or incomplete execution.

UX is never just about following rules. Context matters. What works on a desktop may make no sense on a smartphone, where desktop-style shortcuts often become irrelevant. Effective UX always requires considering the actual use case and environment, not just adhering to guidelines.

Much of UX is still heuristic, shaped by lead designers rather than a fully scientific approach. Apple follows top-down patterns; GNOME aspires to logically consistent, user-focused design but too often fails in practice; Microsoft and Google prioritize flexibility and familiarity. Each reflects organizational priorities more than objective UX science.

Unfortunately, there is so much to consider in UX design, but 25 years of experience cannot be compressed into two sentences. If it could, this discussion would look very different. Not that i did not try, my last attempt endet in a book with 400 pages. And especially the experience when to use what rule is hard to teach.

You didn't get my point anyway. Apple may invest a lot in UX, but whenever I use an iPhone I'm lost. It takes me ages to get used to it. The same applies to macOS. Is it bad UX or just lack of familiarity?

Whenever I use Gnome (I don't use Linux much, I need Windows for my job and for my mixing, I give it a spin every now and then) I am never lost. On the other hand, I'm infuriated by the small graphical bugs, lack of polish once you stray off basic usage and general futility of designing stuff on Linux because you will always have to deal with at least three design languages anyway, once you use third-party apps (which is always).

Windows... I'm used to it. But there are a lot of inconsistencies there as well (or bad UX that persists, such as the traybar, due to their imperative duty to support applications written even twenty years ago when the traybar was a new concept; yet, applications are still coded to use the traybar today). I also never know what I'm going to get: clear fonts? Badly upscaled UI? Blurry UI?

Back on topic. Ardour isn't really badly designed. I can see why certain stuff has been placed there or implemented in a certain way. It does make sense. You do need to read up on how to do advanced stuff, but that's a given when it comes to very specialised software (I don't expect anybody to mix proficiently in Logic without learning how to do so beforehand). I can set tracks and buses just fine in Ardour as in any other DAW (but Reaper does it best really, by completely eschewing any distinction between audio or MIDI, tracks or buses, folders, etc. and it's just natural to use). There are some features in Ardour that were there much earlier, and in more advanced form, than in Reaper (for example analytics on mix renders). There are some things that you simply can't do in Ardour but are extremely easy in Reaper. There are things that are very convenient or awesome to have (manual FX oversampling, native delta auditioning, containers, parameter linking, etc.) that are only present in Reaper (and maybe a few other DAWs I am not familiar with) and that I have learned not to expect elsewhere. But Reaper is also, probably, considered a UX nightmare by many (and they would be right on certain regards - discoverability being almost nil). But you know what? I still use the old V3 skin in Reaper, which looks straight out of the early '00s, because that's what I'm used to. On the other hand, those "naive users" that UX still target, so as to make apps more enjoyable to use by them, still manage to waddle in utter despair once they have to do something that is not completely elementary, even in the best designed apps. So sometimes I wonder. Is all this UX talk maybe a load of bollocks? Like, not like it's untrue, but maybe ultimately irrelevant?

[Tiles]

That’s certainly an entertaining take on UX. By that logic, we might as well send all designers home. Knowing this upfront would have saved us both some explanation.

Back on topic, most of what you describe about Ardour actually reinforces the relevance of UX rather than undermining it.

Saying that Ardour makes sense once you understand why things are where they are is not a defense of its UX. That is a description of learned behavior. A usable system should not require prior justification to feel coherent. The fact that you need to read up on how to do advanced things is expected for professional software. The fact that you need to read up on how the mental model works at all is a UX issue.

UI and UX design exists to make complex software humanly manageable. Good design is defined precisely by this. That even highly complex software remains usable. The underlying fallacy is the assumption that the harder a piece of software is to use, the more professional it must be. No, it's just a proof that the designer did a bad job.

Comparing Ardour favorably to Reaper while simultaneously praising Reaper for abandoning rigid distinctions highlights this perfectly. Reaper’s core strength is that its underlying model is simpler and more consistent, even if discoverability is poor. Ardour, by contrast, exposes a more fragmented conceptual model that the user has to internalize before fluency is possible. That is not neutral. That is a design choice with UX consequences.

Pointing out that Ardour had certain advanced features earlier than Reaper is also orthogonal to UX. Feature availability is not experience quality. A feature can exist, be powerful, and still be poorly integrated into the workflow. UX is about how those features are discovered, combined, and operated under cognitive load, not about whether they exist at all.

The fact that there are things that are trivial in Reaper and hard or impossible in Ardour matters. UX is not judged by whether something can be explained after the fact, but by how often the software fights the user’s intent in real workflows. “I can see why it was designed this way” is not the same as “this supports my work efficiently”.

Your Reaper skin example actually undercuts your own argument. You are describing familiarity and muscle memory, not good UX. UX design is not about preserving whatever a user happened to learn first. It is about reducing the cost of learning, reducing errors, and making correct actions easier than incorrect ones. Preferring a dated skin because you are used to it says nothing about UX quality, only about habit.

Finally, the observation that naive users still struggle once they leave basic usage is not evidence that UX is irrelevant. It is evidence that UX does not magically remove complexity from specialized domains. Good UX does not eliminate learning. It structures it, scopes it, and prevents unnecessary friction. Professional tools still need good UX precisely because their users operate under time pressure, cognitive load, and real consequences.

So no, none of this suggests that UX is “a load of bollocks”. It suggests that UX is being conflated with taste, familiarity, or ideology. Those are not the same thing.

I will stop here, as this is moving beyond the scope of the original topic. Thanks for participating.

[dawhead]

Reaper’s core strength is that its underlying model is simpler and more consistent, even if discoverability is poor. Ardour, by contrast, exposes a more fragmented conceptual model that the user has to internalize before fluency is possible.

Asserted, so far, without evidence.

I regularly hear from DAW users who will say variants of the following two things:

1. "Ardour is so much easier to use than Reaper (or any other DAW) I have tried"
2. "Ardour is so much harder to use than Reaper (or any other DAW) I have tried"

Who's right? The answer is both, and neither.

There is no DAW design that is correct for everyone - all users come to any piece of software with a history (even if that's just an empty history, though this is unlikely in 2026). But even more important, workflows matters intensely. Even people doing nominally similar things (in-the-box EDM, for example; or two-voice podcast editing) can end up working in wildly different ways and want different tools to be more or less readily available. Even things as basic as modal versus non-modal editing styles play an important role here, and "we all" know that the vi/emacs war on this front was never settled in any sense whatsoever.

You can believe all you like about some principled UX design - I don't doubt that there's "good" and "bad" - but I strongly believe that there is no design that is the right one for every DAW user. I used to get upset when people complained about Ardour's usability - after 25+ years, I now understand that while there's always room for improvement, ultimately there's absolutely no point in us chasing every user. We try to focus on people who "get" the Ardour way of doing things and enjoy it. If that's not you ... that's totally fine. Because I'm 110% used to that, for example, I find Reaper completly inscrutable, I find its "underlying model" somewhere between odd and impossible, and its UI arrangement cumbersome. But that's just me ... for some people Reaper or Logic or DP or whatever truly will be a superior choice, and there's nothing to be done about that. I assume that you don't go around lecturing folks on which code editor they ought to be using?

[Tiles]

You are absolutely right that there is no single DAW that is perfect for everyone, and no serious UX professional would claim otherwise. Different histories, habits, and workflows inevitably shape how usable a tool feels to an individual user. That part is not in dispute. In fact, I have to caution against completely overhauling the UI of a well-known software in a dramatic, revolutionary way. Such drastic changes have ruined companies in the past. At established software, UI changes need to happen evolutionarily, not radically.

Where I disagree is the implicit conclusion that this makes UX principles largely subjective or unfalsifiable. While preference varies, usability is not purely a matter of taste. There is a large body of empirical research in HCI and UX that shows consistent patterns across users. Nielsen’s usability heuristics, Norman’s concepts of mental models and affordances, and decades of usability testing all demonstrate that certain design choices systematically reduce error rates, learning time, and cognitive load across very different user groups. Even color theory plays a role, and we take available themes into account in our design decisions.

For example, consistency, both internal and external, is not an ideological preference. It is measurable. In controlled studies, consistent interaction patterns lead to faster task completion and fewer errors, even when users initially prefer a different style. Similarly, discoverability is not subjective. If a significant portion of users cannot find a function without documentation or prior instruction, that is a usability problem regardless of whether a core group of experienced users is comfortable with it.

As a concrete example, a common complaint in many DAWs, including Ardour, is the confusing audio routing system. Sends, busses, and outputs are often hard to distinguish, hidden in nested menus, and labeled inconsistently, which increases cognitive load and errors. A simple fix would be clearer labeling, color-coded grouping, and an inline drag-and-drop routing editor to make these functions immediately visible and easier to use.

Workflow differences also do not invalidate UX evaluation. Good UX does not mean forcing everyone into the same workflow. It means making the underlying model legible, predictable, and learnable. Two users can work very differently and still benefit from clear state representation, visible modes, reversible actions, and sensible defaults. Modal versus non-modal editing is a good example. Both can work well, but hidden or implicit modes are repeatedly shown to cause errors and frustration, especially for new or returning users.

The vi and emacs comparison actually supports this point rather than undermining it. Both editors have extremely strong internal consistency and very clear underlying models. That is why they remain usable despite their differences. Tools that lack a coherent model or violate their own rules tend to be the ones users describe as inscrutable, regardless of personal taste.

Focusing on a specific audience is a valid product decision. No argument there. But that is a different claim from saying that usability criticism is mostly a matter of personal preference. When users struggle for the same reasons, when onboarding repeatedly fails in the same places, or when common tasks require unnecessary indirection, those are signals that can be analyzed and improved using established UX methods.

So yes, there is no DAW that is right for everyone. But that does not mean that all designs are equally sound, nor that UX principles stop applying once a tool targets a specific kind of user. Preference explains variance at the edges. UX explains the center of gravity.

What we always take seriously in our project are user complaints. They have to live with the software, and their feedback is central to improving usability. Unfortunately we can't let them do the design and the fix for the problem. That's my job then.

[dawhead]

... a lot of stuff ...

I think one fundamental issue here is that we are in a transitional state in which traditional audio engineering is still an actual skill at the same time as "bedroom production" is growing in significance.

The design of software (and hardware) for people who use it all day every day calls for some notably different UX principles than designing functionally similar software that is targetting more occasional users. Not only that, but if you think you're targetting people with significant experience on hardware systems with similar functions as your software, your UX design space looks pretty different than if you think you're targetting people for whom mobile apps and macOS are the bees knees.

The design of traditional consoles, for example, is in many ways a UX nightmare. It is easy to imagine lots of ways of improving it when you do it in software, and yet those consoles were very much loved by their users. I would claim that this is largely because they used them so much that issues like "discoverability" and "color coding" ceased to be important. Fixed physical layouts (frequently a liability in software) were actually an asset because it allowed muscle memory to play a critical role in console use. Stuff like your complaints about sends/returns/busses just don't make any real sense in console land - people just learned how they worked on their console and got on with the job. Another example I like to cite are the two different VCA models used by SSL and Harrison consoles (one allows multiple VCA assignments, the other allows stacking/heirarches of VCAs, neither allow both). From talking to people at both companies as I've done over the years, it's quite notable how users just didn't bother to ask for the other version - they got on with the tools they had (Ardour of course implements both). Some of that may because they perceived as change as impossible ("it's hardware!"), but I think there are more subtle forces at work too.

So now we have 1 or 2 or 3 generations that have very little experience on traditional consoles, and who have a reasonable expectation that their DAW will benefit from the sort of UX possibilities that exist only for software. They don't care at all about how consoles worked, and they think that DAW software should use UX models taken from other domains.

We also have DAW workflows that don't correspond to anything that used to be done in hardware (and paradoxically, over DAW-less land, hardware workflows trying to model things that used to be done in software - here's looking at you Elektron et al.)

So the overall picture of what we're actually to do in a DAW is quite confusing. Ardour generally puts itself in a group loosely defined as "users who spend a lot of time with the application, have some degree of exposure to traditional console workflows, and have a hacker mentality even if they are not explicitly hackers in any other domain". That makes us quite unfriendly for the "Ijust started playing (piano|guitar) and I want to record a song I just created" crowd, for example. Like Unix, we tend to give you enough rope to shoot yourself in the foot, which for some people is great and for others (as you've demonstrated in this thread) is an anathema.

What we always take seriously in our project are user complaints. They have to live with the software, and their feedback is central to improving usability. Unfortunately we can't let them do the design and the fix for the problem. That's my job then.

Ardour is the same, with the clarification that we listen to our users, not random people on KVR with an opinion about more or less any DAW in existence.

[Tiles]

Ah, so none of what I said actually got through. No wonder the user base is so small. Well, I tried. Good luck with further development.

[jens]

what is the current status on ARA support?

I read through a thread in the Ardour-forum a while ago where you devs (i.e. Paul and a second one) appeared - frankly put - rather ignorant on what ARA actually does/what advantage(s) it offers...

Robin and I spent some time last year looking at ARA. It is is INCREDIBLY complicated to implement, and to do it properly requires providing new thread and buffer designs. It's not that it is badly designed - most of the reasons it is why it is seem relatively obvious and well-founded. But it will/would be a huge amount of work and so, despite being urged on by some folks up the Harrison ownership chain, we decided to defer it for now.

That's a well-reasoned reply one can't argue with - thanks!

We would like the integration with melodyne (and maybe, what, 2 or 3 other plugins?) but the bang-for-the-buck just doesn't seem worth it right now.

That bit is somewhat different though. The way I remember it, in the thread I was referring to you were arguing along the lines of "it is not that difficult to manually transfer the program material into Melodyne after all"- which is totally missing the point of ARA however (many folks make that mistake though).

There's many ARA2 compatible plugins now from a long list of software-vendors and new ones are popping up left and right on just about a monthly basis. The bang for the buck is tremendous.

[ampetrosillo]

Ah, so none of what I said actually got through. No wonder the user base is so small. Well, I tried. Good luck with further development.

Well, you didn't really say anything specific.

[Tiles]

Yeah, just a few essential UI/UX points. Totally insignificant, of course. Tiny, obvious things that apparently fly right over developers who don’t get it. Already familiar with that, so no issue for me. Good luck with the project.