Hi Paul, just wanted to say thanks for working so hard on Ardour. I just started playing with Ardour in Fedora on my Framework laptop, but I've been thinking about buying a M1 mac to make music because I miss Logic and Ableton. These release notes have got me hyped because now I might not want to! I'm very excited to try out the clips and freesound features. I'll definitely be buying a license soon. You (and the rest of the brilliant Ardour contributors) seriously rock!
Thank you. Just to be clear about one thing: nobody buys a license for Ardour, it is released under the GPL.
You can choose to pay us for the service of building it for you, or if you like, providing a ready-to-run version that we can actually support. That revenue allows myself and other Ardour contributors to work on Ardour as a way of making a living.
Thanks also, I had the privilege to exchange with you on the linux-audio-dev mailing list a few times way back in the time of quasimodo and creation of LADSPA, I learned so much thanks to your dedication and knowledge about audio programming and how to create an useful api !
Thanks for making Ardour! When will it be upgraded from GTK2 (which reached its end of life two years ago) to GTK3 or GTK4, and are there any plans of supporting SDL2 instead, to ensure stability and portability over time?
There are zero plans to ever move to GTK3 or GTK4 or GTKN.
There are dreams & aspirations to drop our use of GTK and fall back on GDK (just a window & event abstraction), but this is not on any timetable because it means reimplementing text-entry, menus, tree/list views and the file browser.
By "zero plans" do you mean you have evaluated them and decided they are incompatible with Ardour's goals, or just that there is nothing in the pipe or on the roadmap to do the port?
One major feature that gtk3+ (or SDL2) brings is Wayland compatibility.
Porting a 600k line codebase to a different GUI is a fool's game (the vast majority of Ardour's code and complexity is in the GUI, not the backend).
We did it once before, from GTK1 to GTK2, which should have been easy. And indeed, the actual GUI toolkit switchover was relatively easy. The problem is that along the way, you keep running into other issues and ideas. We likely could have done GTK1 to GTK2 in a month, but it took nearly a year.
We have no need of traditional desktop GUI toolkits (or SDL) except for the 4 widget classes I mentioned. We have our own internal canvas-based "toolkit" that is Cairo-based, and thus only requires a window+rgba-buffer+event abstraction.
We do plan to do so, but it's not a high priority for us at this point. A more urgent plugin-related task is an internal redesign to be able to handle multi-output-bus VST3 plugins. Unfortunately, Steinberg used a totally different model for this than Apple's AudioUnits (which was the basis for the existing design in Ardour), and some rather severe changes are required to get VST3 plugins that do this to work.
CLAP doesn't really much for an Ardour user that isn't already addressed by LV2 or VST3, so although we do want to support it, it's not really on any critical path (other than wanting to support the general move to a not-owned-by-one-company plugin API).
i’m a long time cubendo user. i’ve tried to switch to ardour a couple of times (although perhaps lacking in sustained effort), but i can’t ever quite seem to get the same productivity in my workflows - e.g. multi-track slip editing for a whole drum track recording, sidechaining effects, and routing (a non-exhaustive list). this is most likely a time/experience issue, to be fair.
what tips would you give me for making ardour feel a bit more familiar? i understand that’s a very vague question, and a vague response would be justified :)
It's not something I think I can usefully address in HN comments, but please free free to join us on our forums at discourse.ardour.org or IRC at #ardour on libera.chat and we'll be happy to listen to your workflow and make some suggestions (which you're free to ignore, of course).
Thank you Paul, the story of Ardour is really inspiring. Have you looked into potentially porting it to WASM and running in the browser? Is there a Figma for audio already?
Running this sort of thing in a browser has become more and more feasible, but I still consider it fundamentally a broken idea. Even if the browser environment started to offer sufficient low level OS interaction (e.g. setting relative real time thread priorities, using SIMD correctly for metering and gain control, and lots more), I can only really see one reason to want to do this: ease of "delivery" of the software to the user.
Porting the 80+ libraries we use to wasm is no laughing matter, and it would be even harder to run plugins, since each of them would have to be ported by their respective developers (in the case of proprietary plugins. A browser based version that could not run Kontakt or Valhalla Shimmer would be a significant step backwards for most serious users.
However, you can already run Cardinal (the FLOSS-ier fork of VCV Rack) in the browser, so at this point it's anyone's guess where this idea might lead us.
That makes sense, cause it's true that the audio world -compared to design- is really plugin heavy. However, VSTs are mostly used by real pro users and the distribution the browser offers is not to be dismissed easily. Amateurs could get away with a few good plugins. When they are ready to make the transition, a native app or extension could be installed. But it would open an interesting door to quick editing something online, and even collaboration if integrated.
1. "VST" is often used as a synonym for plugins, but it absolutely is not. It's one particular plugin API/format.
2. If you're doing in-the-box composition, every sound you work with probably comes from a plugin. So the idea the plugins are mostly used only by pros is not really true. Synth choice is a hot topic and highly subjective issue, I don't think people would want to be heavily constrained there.
3. "quick editing" is already available online. Not much point with us trying to compete with that.
No native Pipewire API support and none planned. On Linux, there are audio/MIDI backends for ALSA and JACK. Pipewire mostly supports the JACK API (and likely will do so completely in the near future).
[EDIT: if you can work with playback only (e.g. during editing or mixing), we also have a PulseAudio backend on Linux that will (like JACK) also talk to PipeWire. ]
That was made using Rack 1. You could use Rack 2 or Cardinal to do the same thing, though some of the modules I used for those pieces are not available for one or both of Rack 2 and Cardinal. But that should never limit you - even Cardinal has more than 800 modules.
Ardour revenue is about US$180k/yr at present. I make a reasonable middle-class income from it, help support another full time developer, and put aside any surplus to help pay other people associated with the project (e.g. website, documentation).
The other day I bought Bitwig because I was looking for this exact thing on Linux. I don't regret it one bit, but it's amazing to see the beginnings of an open source solution to this! Hats off to the contributors who pulled through and made this happen.
If you're interested, there's a $20 plugin for REAPER that introduces a fantastic clip-launcher workflow, complete with MIDI controller integration/remote controls.
Didn't know about that, thank you! (Their terminology is confusing though: a "VST" that only works in Reaper is a Reaper plugin, not a VST proper...?) But anyway, will try it!
Reaper has it's own specific plugin format and language, JSFX (no relation to javascript), so that's probably why they specify it uses the VST format. But also relies on Reaper specific APIs making it only work in Reaper.
JSFX are distributed as text files, not binaries, and they can even be edited on the fly while the DAW is running. I don't think they can be called VSTs, but they sure are extremely powerful (I have written a couple myself).
JSFX can also be run in most DAWs using ReaJS, a JSFX VST host written by Cockos (not updated in a while, so some recent features of the language won't work), or another similar thing called YSFX.
Playtime probably uses Reaper-specific API calls and UI manipulation, but why the author chose to write a Reaper-specific VST instead of a plugin, IDK.
They aren't VSTs but that's my point. A "Reaper plugin" to the community usually means a JSFX plugin.
Playtime is a VST plugin, not a JSFX plugin, but it also relies on Reaper specific API calls making it incompatible with other DAWs that support VST.
It matters because you'll find it in the VST section of your Reaper plugin list and I believe Steinberg also requires you to use the VST branding on any plugins using the VST SDK
VST isn't an open plugin format and it doesn't guarantee compatibility across all hosts. It's a source-available format owned by Steinberg who grants financial free use of it (but not free use in the FOSS sense)
Reaper has some VST(TM) extensions that only it supports. So if you create a VST(TM) plugin that uses one of them, it will not run (correctly) in other hosts.
That looks awesome, I'd be interested in giving it a whirl once they add Linux support! Currently I'm sticking with Bitwig for the excellent DrivenByMoss Push1 integration, but eventually I'd like to give Reaper a try (since it has the same Push1 plugins).
I've used Ardour to mix-down my last few tracks. I write EDM and I decided to try creating a track entirely in Ardour. Coming from "clip" or pattern based sequencing, working with Ardour was pretty painful. I went back to Ableton for sequencing and arranging.
Glad to see they've added a clip based workflow, makes it a lot more useful for the way I do my sequencing and arranging.
I don't know about recent drama but just want to add I won't ever buy Bitwig because if their servers have an error, it can lock you out of the app or crash running sessions. These have happened multiple times. Even if you activated Bitwig offline, it will still try to reach the licensing server every few minutes. If the licensing server throws a 500 error, it refuses to open and closes any running sessions without saving.
The recent drama has been resolved. For a week or so there was some uncertainty whether all new Bitwig devices would be part of the Studio edition and therefore covered with the cost of the update plan. Bitwig (the company) put out a paid add-on with new devices and announced that there would be other paid add-ons in the future. That caused a lot of negative responses in the community. After a week the Bitwig company apologized, made the add-on part of the regular Studio distribution and ensured that in the future all new devices would be part of the Studio - effectively no additional paid add-ons.
The thing with the licensing server has been fixed. I tried that by turning off my router. No session closing and no data loss whatsoever.
It's actually a different issue. If the servers are completely down, or inaccessible (blocked or you're actually offline) it uses the offline license check and works fine.
If you're online and the servers are online but having issues, like returning a status 504, your local license gets revoked. Even if you chose offline activation during installation it still tries the online activation method every few minutes. If there is a server response but it's not status=200 Bitwig considers it a failed license check. Offline activation checks will then no longer work until their servers give you a good response.
Reason has a similar system, which is pretty annoying. I wonder how hard it would be to write a "yes server" that would simply respond "ok" to any activation request. Some keys must be floating around if one looks hard enough; or one should be able to find them in the local executables themselves?
Ironically it works if your internet or the servers are legitimately offline. So just block the domain. But if the servers are having trouble and return an error status code, it revokes your license until it gets an OK status again.
I wanted a DAW to record my own fledging attempts at electronic music. I took a vow in the 80s to never use Windows, Apple systems seemed overpriced, and I had years of *nix experience, including a bit of Linux. In the late 90s there was a Linux app called "Multitrack" which seemed capable on the surface, but it turned out not to be. I called Digidesign to ask them if I could port ProTools to Linux for them (for free), and they laughed. So I thought "how hard could it be to just write my own?" ... 22+ years later, here I am.
Ardour is awesome and shows that specialized niche software can compete or even out-compete commercial proprietary software (like QGIS in the GIS space).
I hope it will be around for a long time and it's a nice piece of software, thx Paul.
As someone who recently started dabbling in this area, can someone explain how Arduor is different from Audacity in its features. I know the telemetry issue in Audacity, I'm interested to understand feature differences and ease of usage.
Audacity is primarily an audo file editor: you load (or record) a file into it, carry out destructive edits (i.e. the data on disk is modified), and then save the result.
Ardour is a digital audio workstation, which mostly implies that it is a non-destructive, non-linear system. Edits in Ardour do not change any of the media data on disk (everything is done with meta-data). Ardour is designed to handle track counts that Audacity could not dream of (100+), does realtime FX processing (coming to Audacity in the next version) rather than having to process the data and write a new file on disk, and is generally much more capable for handling multi-track audio.
Each one has its place. If you are really just editing an audio file, Audacity is likely to have less of a learning curve. If you involved in music creation or composition or recording, Ardour is much more likely to be the appropriate tool.
Audacity is a lot simpler from what I can tell. It is meant to record and edit audio without doing anything fancy. Ardour on the other hand has lots of additional functionality, such as a fully featured mixer with plug in support and the recently added clip launcher. There is probably a lot more to say, but if you are serious about making music, definitely choose Ardour. If you just want to record something quick, or something simple like a voice recording, Audacity can get the job done.
Both Audacity and Ardour ping the server to ask whether a new version is available. Both applications allow disabling it. The difference between them in that sense is that Ardour does not (yet?) provide a way to easily submit a crash report — another common feature in software these days. How much of telemetry that is, is anyone's personal decision, I think.
Ardour does not require JACK and has not for many years. Unfortunately the internet is riddled with out-of-date and inaccurate information which makes many people believe that it does.
I installed a copy of Ubuntu Studio on a spare machine a couple of years ago. I had come from Windows and Reaper and was used to one app where everything was controlled by the app. I was relatively new to Linux but kind of new my way around. But I found the principal of separate applications talking to each other a compelling idea, but in practice totally frustrating! I had VSTs I wanted to use and I got some to work though I don't remember how, but many synths just wanted to act alone via communication. Has anyone done anything to make all that less of a headache? Or was I doing it wrong?
Plugins on Linux work just the same way they do on macOS and Windows.
But yes, it is true that to some extent, there was a tradition from the late 90s to the 20-teens to create synths as standalone apps for Linux, connected via JACK.
That is really going away now, and you can run U-he synths, Helm, Vitalium, Serge and many others as plugins just like you do on macOS and Windows.
Exactly opposite situation in my case - my Ubuntu Studio rig has been rock solid for tracking and many projects .. but the good news is that even if, for whatever reason, you can't qite grok things to be as productive as a pro Ubuntu Studio user (hint: you can) we have all the good things happening in ZynthianOS to explore, anyway - and this just wraps up the same essential goodies into a hardware device that is push-button-user friendly:
I've used LinVST in the past to run Windows VSTs on Linux with mixed success, but it was more of a hit and miss; today I'm extremely happy with Yabridge which is a lot more polished, doesn't crap out at every WINE update and also is much quicker to operate.
I've switched from ardour to reaper after having issues with plugin latency at some point in the - now - pretty distant past (different tracks didn't time-align after the sum of plugin latencies diverged on their respective tracks).
I kept my subscription for ardour, though, because I think the project is awesome.
Sadly now I've grown used to another set of quirks (reaper's), so switching back seems quite unlikely. Still gonna keep that subscription running...
I use ardour as a mixer for live streaming, it works great, but I'd love native Wayland support and some "mini mixer" GUI mode with just faders and mute status for each bus.
I've looked at Ardour in the past but GTK put me off from investing serious time into it. Now that there is REAPER, I have to ask, what does Ardour do better and why would one pick Ardour over REAPER?
Reaper is a fine DAW, and there are many fine DAWs. For the most part, which DAW is better for a given user depends a great deal on their prior experience, specific expectations and likely workflow. Neither Ardour nor REAPER are "better" than the other - they are different, and some people will love one and hate the other. More typically, some people will find a particular workflow that they use cumbersome in one of the DAWs and easier in another.
If you'd like, you can listen to myself (lead dev of Ardour) spend 2.5hrs chatting with Justin Frankel (lead dev of Reaper). It won't do much to answer your specific question, but might reveal that the similarities in our development processes and history and goals are much broader than you might expect: http://adc.equalarea.com/2022/02/07/adc1/
If you're a user of Ardour, why would our choice of GUI toolkit have much impact on your use of the program?
I appreciate the time you took in crafting this response, I will listen to the conversation that you linked.
Regarding GTK, I could never stomach the specific "feel" that it has, and it's also been incredibly buggy for me on platforms other than Linux, and I use macOS and Windows a lot too. I haven't found a single GTK app that I can tolerate using on Windows or macOS so far. I find QT a lot better in that regard.
I was a heavy user of Inkscape (GTK) back when there were no free alternatives, but when Krita (QT) matured I switched to it and never looked back.
Not much of Ardour uses GTK (the editor and mixer all use our own stuff). You will find GTK in text entry, treeviews, menus and the filebrowser. In the long term we'd like to drop back to just GDK (window and event primitives), but those 4 "widgets" are major things to implement correctly, and that's not likely to happen any time in foreseeable future.
What's your problem with GTK? I mean I like good UIs and this is what attracts me. So Ardour has a good looking UI (IMHO). How does the window toolkit impact you?
> I mean I like good UIs and this is what attracts me.
Hard disagree. DAWs like Logic, Ableton, and Bitwig have consistent, straightforward, and (given the amount of data) relatively uncluttered UIs. The open source or cheaper DAWs, like Ardour and Reaper, are a veritable explosion of inconsistent and different sized widgets, fonts, and styles. Reaper also apparently likes massive walls of random text for its menu system too. This is only too typical of open source software: there's no UI designer who can rein in the chaos.
You don't know that we (Ardour) have no UI designer, you just don't like the result of whatever design process we use. You also don't seem to have considered that there are lots of Reaper users who actually love it's user interface, including those massive walls of text in its menus.
It's fine to say "I don't like (Ardour|Reaper)'s GUI, but I do like Logic, Ableton and Bitwig". There's not much point trying to go beyond that. I get email from about 1 person a week, with about a 50/50 chance of either "I used Logic/other-DAW for years, but Ardour is so much better looking and easier to use" or "Ardour is a piece of shit and ugly as hell, nobody can use this crap". Which is pretty great hint that large swathes of DAW UI/UX design remains extremely subjective and path dependent.
> You don't know that we (Ardour) have no UI designer, you just don't like the result of whatever design process we use.
So do you have a professional UI designer or not, and who is he?
I think UI design is all about being consistent across modes, being tolerant, making common things easy to do and easy to discover while still making the less common things possible. I think it's a pretty well understood field at this point. I do not think it's about prettiness or visual consistency, but visual consistency is certainly a signal that tells us that the other elements in the UI design may be lacking a designer's touch. So let's look at that.
I count no less than eight different fonts and font sizes on this screen. Use of whitespace throughout is terrible: for example, look at the placement of the red light snugged up right next to the "Lock" button rather than the Iso button. Speaking which, I presume Iso means "Isolate" while "Grp" means, well, let's assume it doesn't refer to the Grp A4 Synthesizer. Why do you shorten in some ways by removing vowels, and in others by brute truncation?
You also have literally dozens of different button heights. Consider just your faders. Put aside the giant red button. The R/L pans are 32 pixels tall. The In button is 38 pixels tall. The Lock button is 36 pixels tall. The Solo button is 42 pixels tall. The buttons at the bottom are 32 pixels tall. For no reason at all it seems.
You also seem to have tons of different widget widths. Let's consider the VU meters. The Meterbridge meters are 28 pixels wide: the Mixer meters are 24 pixels wide, and its stereo channels are 14 pixels wide (and with completely different dB markings as well) The per-instrument meters at the far left are 16 pixels wide The stereo meters above them are for some reason 10 pixels wide, and together they're 22 pixels wide and so don't line up with the mono meters below them. And finally the global stereo meters up top are 28 pixels wide. What?...
Text styling, justification and clipping is just kooky. Look above the second fader. Vocal, 2, and 0 (which looks like the null set, not a zero, due to weird width) are all centered. Then Fader and AuDynamicsPro are left-justified (And AuDynamicsPro is cut off because it's not getting resized). THEN all the parameters underneath (compression threshold -- again cut off in an ugly way, headroom, expansion ratio, etc.) are all centered again. And they are for no good reason lower-case only. So you have both capitalized case, lower-case-only, and upper-case-only strewn throughout your layout.
To the left of the fader you have "Strips" and "Show". The Show checkboxes are almost invisible thanks to the dark-charcoal-on-black color scheme. Also thanks to your nearly invisible charcoal-on-charcoal scrollbar, you can't read the strips. What's "Claps F"? Why is the "+" so gigantic,and why is it gradiated when no other icons are? I presume the divider can be expanded, but again it's nearly impossible to tell due the charcoal-on-charcoal.
Why are your In, Out, Solo, Audition, and Feedback buttons different colors from the other ones? Why are some of your icons antialised, but others (like the thing to the left of the scissors, or the thing to the left of "No Grid") not? Why are the console buttons (play/record/etc.) smashed together horizontally into thin strips, rather than giving them the standard width afforded to buttons of this importance? At least you could make them square to match their icons. Why is your Tempo and Meter in an incomprehensibly small font? Why do you have two different green colors for fonts?
I am not a big fan of Ableton (say). But its interface is more consistent, much less busy, and much more approachable than Ardour. This is the hallmark of open source software: it tends to lack a hegemon who will sit down and (1) remove features to simplify the interface and (2) force a consistency in design and modality on the software. I will say that what I don't like about Ableton is that it tends to have a lot of mystery-meat interface widgets which don't explain their purpose. But at least they're consistent. :-)
Now Ardour is FAR better than the interface nightmare that is Reaper, a veritable explosion of every single interface style, coupled with a seeming lack of understanding regarding how menus work best. Reaper's interface is objectively bad, full stop. Now there might be people who love it, but I'd wager that's primarily because those people have ego investiture in the product, and ego investiture comes with blinkers. We get heavily involved or invested in a product and it becomes our identity. This should never be an excuse for making a poor product. And compared to practically everyone else out there, Reaper's interface is really, really bad.
There's some valid criticism here, which I'll put in our issue tracker.
However, you could have started with a screenshot of something current instead of 7 years old. Several if not many of the issues you've mentioned have already been addressed.
The problem with the UI/UX paradigm of "making common things easy to do and easy to discover while still making the less common things possible." in the context of a DAW is that what's common and less common depends a lot on workflow.
Specific details;
> Why are your In, Out, Solo, Audition, and Feedback buttons different colors from the other ones?
In, Out and several other buttons are tri-state, not bi-state, to indicate, for example "muted because you soloed something else" rather than "not muted" and "muted because you muted it". The Solo/Audition/Feedback buttons are global indicators that also function as buttons.
> You also have literally dozens of different button heights.
Vertical space is at a premium in a mixer-style layout, so many buttons are sized to fit their contents rather than have consistent sizing. And in general, we eschew "all buttons should be the same size" anyway, because we want to prioritize some and deprioritize others.
Ableton is much less busy, but also presents way, way less functionality in their mixer (compared to Ardour's, or a large scale mixing console, it's almost a toy). You can certainly argue that it offers the right level of functionality for most people, and that busying it up is a negative for most users. I'm not even sure I'd disagree with you, but we've tried to build software for the sorts of people who are comfortable with large scale mixing consoles (or would be, if they could afford one), rather than bedroom producers who get just what they need and not much more.
> Why do you shorten in some ways by removing vowels, and in others by brute truncation?
22yrs of user feedback, mostly.
> And compared to practically everyone else out there, Reaper's interface is really, really bad.
Although your explanation of why this might be could have some truth, the sheer number of people who love Reaper's interface really argues against the claim that there's some sort of "objectively bad" here.
> Then Fader and AuDynamicsPro are left-justified (And AuDynamicsPro is cut off because it's not getting resized). THEN all the parameters underneath (compression threshold -- again cut off in an ugly way, headroom, expansion ratio, etc.) are all centered again.
"Fader" and "AuDynamicsPro" are processor (plugin) names. The centered texts are parameter names (indicated here by justification, not just color), and the actual text shown there is based on the names assigned by the plugin, not by Ardour. We do not ever resize-text-to-fit, which I consider appalling UI design.
> Why are the console buttons (play/record/etc.) smashed together horizontally into thin strips, rather than giving them the standard width afforded to buttons of this importance?
Because a large fraction of the user base will use either (a) a control surface of some type to control these, or (b) keyboard shortcuts (the ubiquitous space bar, for example). Because of this they are not actually very important when it comes to mouse-ability, but play the role of indicators more of the time.
Hey! First of all, thanks for all your hard work on Ardour! Just like you, I decided not to use Windows for my media production workflow some years ago, and set out on a journey that has been as much enlightening as frustrating. I've used Reaper, Renoise, Bitwig, even Ableton on Wine, all are great, all are proprietary.
I'm really looking forward to trying out the new clip launcher and the smart ripple editing. I think Ardour just might be the sequencer that all the outboard gear I've accumulated in the meantime is waiting for. I definitely hope so! I guess I just gotta wait a few more days for my distro to upgrade the package (https://github.com/NixOS/nixpkgs/pull/196290) - but that's completely fine.
What I'd like to ask is whether you consider important the issues that I've pointed out on this screenshot (from 6.9):
1. IMHO, the grid lines being Too Damn Bright is hands down the most jarring thing for any newcomer to Ardour. Basically, there's too much contrast on the very thing that delineates/delimits empty, user-editable space, relative to the contrast in screen areas that contain fixed UI controls. It just creates the impression of a barrier in the wrong place. Changing the line color from 100% white to 100% black would be at least a 200% improvement in terms of more betterness; a slider from 100% black to 100% white would bump that up to 300%.
The rest is mostly 1px misalignments that just sort of add up:
2. Top row of pixels in the menu bar is not active. So in full screen if you move the mouse all the way to the top edge of the screen the menus don't work. You can see this when opening a menu - GNOME didn't let me take a screenshot with a menu open lol
3. The 4px gradient border causes the "transport" and "editing" toolbars to look very misaligned.
4. The above border ends a few pixels above the "scrollbar/overview". Apparently there's a dragging handle there - but no hint that it's there.
5. These are the only toolbar buttons that don't have a border. If this is meant to signify that the button is inactive (why does "solo" behave differently from the others?), it would benefit from also making the text a tad dimmer.
6. Icon noclips out of the button.
7. Why the monospace here? It's not aligned to anything.
8. Separators would benefit from either being more prominent, or just being blank spaces. All separators except the one that the arrow points to have N pixels to one side and N+1 pixels to the other. Button text is also 1 pixel below the center of the button (and below the baseline of neighboring labels).
These things are noticeable, and annoying, on a 24" 1440p monitor at 150% zoom. Is this due to the scaling or something else? It simply looks slightly unappealing and "broken-ish", which does not do justice to the underlying engineering effort.
I think this problem plagues virtually all native GUI apps based on FOSS toolkits, and hampers migration away from proprietary solutions, to a degree that is often underestimated. I have some experience trying to get people to migrate to FOSS solutions, and I realize that it's an uphill struggle against BigCos that have whole design departments and can afford to condition people as to "what things should look like".
Computers are scary enough beasts as it is - it's too easy to present either too much or too little information to users, who just expect things to be "intuitive" (i.e. learned helplessness). People who have looked proprietary apps all their lives are prone to viscerally rejecting a solid FOSS product that might even be a better fit for their workflow, just because of superficial glitches like the ones I listed above.
One funny effect of this: users might even identify the problem at the wrong level. They may object to the semantics of the interface ("I don't understand it"), while the problem actually is on the level of ergonomics ("it doesn't feel right"). Maybe they don't want to seem petty.
I know my way around Ardour and the general Linux audio ecosystem well enough to get things done with it, but the reason I don't bring Ardour with me everywhere is ... basically the grid lines and alignment! Please tell me there's a dotfile for that, or that a fix is on the roadmap? :-)
I realize this might be just my "OCD" speaking; I'm still recovering from the heartbreak that was Qt's default font rendering (maybe still is; I think Krita started to look fine at some point, I don't use many other Qt apps...)
But I feel like Ardour might be missing out on a big chunk of useful feedback from people that don't even engage with the product deeply enough to provide feedback - because of admittedly silly things (like 10 individual widgets on the main screen being 1 pixel off) that make them automatically disengage.
Some might say that such users don't have a serious attitude, so why would they be owed any consideration? I believe proprietary software has conditioned them to believe that their opinions don't matter anyway - which in the case of FOSS couldn't be further from the truth, but then again how are they supposed to know that.
So, here I am seriously engaging with this topic in their stead. Sorry for not filing this on the issue tracker I guess . (1) its Web UI basically creates the same impression and (2) I'm weird about creating accounts, that's 1 external and 1 internal reason that combine into nudging me in the direction of speaking up here instead :-)
The WebUI of the tracker is the WebUI of mantis, a powerful if-old-school bug and feature tracking system which we leave (99.5%) untouched.
We're not going to get into a discussion if this useful feedback on HN, but I will file it in our bug tracker. If you'd like to participate in a discussion / the resolution, you know what to do.
> But I feel like Ardour might be missing out on a big chunk of useful feedback from people that don't even engage with the product deeply enough to provide feedback
this is a liability for all software, especially large, complex, creative-tools style software.
