"Some people will no doubt laugh at a few of these "new features", given that they've been in some other DAWs for 20 years or more. That's OK — we laugh too when we see other DAWs finally adding things that Ardour could do in 2005."
I started using Ardour in 2007 and quickly transitioned our studio to it in a big move to Linux for audio production. I'll be excited to reacquaint myself with it later this year on the first analog restoration I've accepted in almost a decade.
The extent of its wonders escapes me now, but I recall with jack+ardour, the new lowlatency/preempt kernel, and some tcp/ip stack fun, we were able to get 40ms network audio latency on commodity hardware, vastly expanding our field processing workflows. Sort of how you can walk out of any venue today and immediately purchase an SD card of the event, we could produce MP3, CDs, and live webcasts of events, ready within minutes of closing with nothing more than a laptop, usb sound card, mics, and the internet.
I also had a little trick for transcription; shorthand with macros! Eventually, I could type them all one handed. Today, you can just pipe through whisper and have subs in every format and language. What an incredible time to be alive.
My lessons learned have been that free, open source software is amazing, and if you don't know something is supposed to be "hard", it can't stop you. Don't let greed or pride make you withhold from yourself.
I'm not a musician, but I've been happily using Ardour to edit a podcast for many years now (paying for a subscription the whole time too) and I really like the workflow I arrived at with it.
One particular feature I like is the ability to edit while playing the audio at 2x speed, which I use to do a quick first pass where I remove obvious things like dead air, coughs, uhms, etc., before doing a second pass at 1x looking for finer details to fix. However, I've found that this feature has been worsened a bit since v6, so I've been stuck at v5 this whole time despite the many new releases. Every time a new version comes out I try it out immediately, but so far v5 has been the superior one for my particular workflow.
I'm not complaining though, for as long as Ardour 5 still runs on my computer I'll be a happy user, and I'm very grateful for Ardour's existence, but I wonder if anyone else uses it the way I do and if they've had the same issue with newer versions.
I'm glad you've been able to see this issue fixed, but I'm wondering (genuinely) why you didn't bother reporting this issue, which kept you from upgrading software that you were paying a subscription for (!) for over three years (Ardour 6.0 was released in May 2020). As you can see from the thread, the Ardour developers were happy to improve the software based on your feedback.
In general (with a few exceptions), open source developers are happy to receive bug reports on their software. It's not like the situation in the Windows freeware world where software is just dumped on a web forum somewhere and reports go into a black hole.
I thought that my use case was too particular, since Ardour's focus is in music production, and that made me shy away from reporting it as I wasn't even sure I could call it a bug. But you're right, I should've.
In Ardour 5 I am able to simply slide the playback speed slider ("shuttle speed control") to start playing at >1x speed, and after releasing the mouse button it keeps on playing at that speed.
In v6+ the sliding part still works, but upon releasing it the slider springs immediately back to 1x, so I can't easily select a playback speed and keep it going. As a workaround there's the varispeed option, but for me it's not as intuitive (it uses semitones instead of "Xs" as its unit), and feels much less flexible. I could probably live with it if I was forced into it, but I much prefer v5's behavior.
"Within this general behavior several variations are available as Ripple edit modes: [...] 3. Interview. This mode works just like the Selected mode with one exception: when you select a range and press Del, this will remove the selected portion of either audio or MIDI without shifting other clips to the left to match the freed space on the timeline. The main use case for this mode is editing interviews where you want the ripple behavior to edit out e.g. periods of silence, while being able to just delete e.g. an out-of-place noise or an exclamation by the interviewer."
I just realized you're an Ardour developer, so thank you for the awesome piece of free software, and I hope my comment didn't sound too whiny. I love Ardour and still recommend it to other podcasters at every chance I have, especially when I see people using Audacity for that task while Ardour is clearly the better option given its non-destructiveness.
Congratulations Paul. For those who don't know, the creator of Ardour is active here and was (historically) very active and helpful on Linux audio lists. I learnt a lot from dicussions on there on the intracies of audio programming. While my work has shifted from Linux audio to Max/MSP these days (I wrote Scheme for Max), in the mid 2000s linux audio hacking was my gateway to the world of programming, eventually leading to a very productive career in tech. Ardour was always a huge "hacker inspiration" to me, it's a truly shining example of how much one smart and dedicated programmer can do. I'm very glad to see it still going strong.
I still feel like track/bus groups, VCAs, and now ad-hoc groups are three different ways of doing roughly the same thing. Are there plans to unify them into a single concept, maybe?
(I know that especially VCAs are different here, but in the end, they are groups of groups if you squint hard enough, are they not?)
No, VCAs are quite different from the other two. They represent an external entity (the VCA) that can be used to control other entities, and they are mixer (signal flow) related only (i.e. have no impact on editing).
Persistent and quick groups are definitely related; we've already a few trenchant observations about what we've done with quick groups, and we will work on taking them into consideration as we refine how this works. But fundamentally, I see persistent groups and quick groups as orthogonal, and their main job is not to interfere (too much) with each other.
What was the main reason for keeping the select-groups from applying to control surfaces? I'm not sure what would be the point of multi-selecting otherwise.
As an aside, is there any way I can add functionality to a control surface (that isn't writing C)? I use a behringer X-Touch (heavily) and moved to Reaper because there were plugins that provided much deeper integration with my X-Touch (which as a result has me working a lot faster in certain areas).
We're still debating the control surface decision. There are two reasons for leaving things alone:
1. hardware surfaces have had different use conventions for a long time (certainly things that look like mixing consoles). They are effectively multitouch devices, and human interaction with them just isn't the same as with a mouse & GUI.
2. for Mackie Control Protocol devices, we already provide a nifty multi-target action there where you just press and hold one eg. solo button and then press another, to apply it to the range that was pressed.
We do not providing scripting for developing control surface support. I've written extensively about my thoughts on Reaper's scripting [0] and I remain conflicted by the questions it raises. There's nothing that can be done in Reaper via scripting that can't be done in Ardour via C++, and a huge amount that theoretically could be done in Ardour via C++ that cannot be done in Reaper. I know this is not a satisfactory answer for people who do not want to master (a) C++ (b) the build environment.
Totally minor feedback in case you value this kind of feedback: the website’s layout is freaking out on my iOS Safari. I can scroll sideways like four page widths and then see nothing at all. Same with the front page.
I've used Cubase historically, but started and now have transitioned back to FL Studio since I can get my thoughts and ideas out quicker than in Cubase.
I've seen Ardour for a long, long time but haven't ever tried it. What, if anything, would I be missing by switching? I primarily do composition, so lots of VSTs etc.
FL Studio is a very, very different sort of DAW than, well, just about every other DAW (including Ardour). If you were moving from Cubase, Logic, Studio One, ProTools, Digital Performer etc., then I'd say you would miss very little by switching to Ardour other than some of the builtin plugins for those DAWs.
But if you have become used to the FL Studio workflow, Ardour (and the list of DAWs above) are likely to feel clunky and unproductive.
Good to know, I didn't mind Cubase's workflow per se, it's just that Cubase was 1) super buggy and unstable, and 2) ridiculously expensive, and updates cost a lot. That also factored into leaving.
I'll give Ardour a try, thanks for the response and congrats on the release!
FWIW, I would absolutely recommend learning a regular linear DAW in addition to FL Studio. I'm not an FL user, I'm a heavy Ableton Live user (entirely because of Max for Live), and it is also "non-standard". There are a lot of things that are much, much faster in DAWs from the pro-tools oriented lineage and it is well worth the few seconds it takes to copy audio from one to the other at times.
I'm aware, I've used Cubase long-term, as well as a number of other ones in the past. FL Studio still gives me the fastest iteration speed out of all of them so far.
However, I don't think that's due to FL Studio somehow being architected better or worse. I just think its score ("piano roll") editing controls are much better than most other DAWs I've used and it gets out of my way for the most part when trying to get things from brain to screen ASAP.
As someone who isn't very well versed in DAWs can someone give a breakdown of how FL Studio is different than others? I see references to "regular linear" below so what makes FL Studio not that? Sorry for the basic questions.
FL Studio groups everything into patterns, and then the patterns are arranged to form a song. Traditional DAWS just place audio/MIDI data directly into the song, without abstracting those pieces away.
If you're making something like hip hop or EDM, where there's a lot of repetition, then this functionality in FL Studio can be helpful. But it also has a lot of weak areas compared to other DAWs.
MPE: nothng is required to record and playback MPE, it's just MIDI 1.0. There's no "nice" way to edit MPE at this time. I can't say right now what priority we attach to this.
One thing we have discovered/realized since tagging 8.0 is that the grid tool will misbehave if you do "wild dragging" with it between existing tempo markers. It is intended to "tweak" the grid in that situation, and is designed around small, "subtle" mouse movement. We may be able to come up with some fixes that make it more robust in the face of users deliberately or accidentally going "wild" with the mouse.
I've just recently started using Ardour after wanting to do so for years. Once you learn the basics like tracks vs. busses and how to use EQ/compressor/limiter plugins it stops feeling daunting. Unfa's tutorials on YouTube were a lot of help.
The screenshot features the excellent Surge synth. Check it out if you don't know it, it's an excellent sounding synth with a gorgeous oscillators section.
There was a time when Sylenth and Serum-quality synthesizers didn't exist for free. Back then, shit like Serge and Helm were really the best you could rely on. Maybe a few free U-HE plugins or your DAW defaults. Today's producers are downright spoiled with so many excellent free options!
It's three times the size of the DAW itself, and unlike the DAW it requires using an installer during which it asks for admin password. Wow. Wonder what happened to "just drop this file into that dir" README.txt...
Users want an installer. You can see what the installers are doing by looking at the scripts in the repo (this is an open source project). Admin permission is necessary to write to the Global VST folder. You can direct your "Wow" at Steinberg if you want. The spec was recently updated to allow for a User install location which has been considered: https://steinbergmedia.github.io/vst3_dev_portal/pages/Techn...
> You can direct your "Wow" at Steinberg if you want.
Plenty of plugins just ship with a README and tell you where to drop em though! Even paid. So especially if it's OSS I don't think it's bad to require a bit of effort from the user especially if it takes unpaid time maintaining the installer wrapper. Thanks for the bundle link!
Of course it's more convenient. You just have to hope a hacker did not replace the link on their website to a modified version or not sneaked some code into their installer code through a dependency. Installer is basically root for free so it's very tempting.
Unless you are running your plugins in a sandbox or have different profiles for different usages, this doesn't make any difference as what is more important, your personal data is accessible from your main user.
Privilege escalation is a big issue for servers and mutualized systems. On a personal computer this is the least of your concerns as your personnal data is more valuable than some binaries in your root filesystem. People are ready to get their precious data pwned or ransomwared but are afraid some process would get root access, this is backwards thinking.
In many systems today an app is sandboxed and doesn't get full disk access unless it's granted. But installer gets full access, since it can plug the password into su/sudo and do whatever.
> If you try to automate the task of adjusting the tempo to follow a human performance (e.g. by tracking transients/onsets), you invariably end up with a mess... With Ardour 8.0 ... switch to the Grid tool (shortcut: "y") and simply drag the grid (lines) to fit the measure and beat onsets that you feel while listening.... The resulting grid accommodates the way people actually perform, rather than how software sometimes thinks they ought to. <
Wow. THIS is something that's been needed for > 20 years. A lot of music has gotten poorer because of the mechanality of grids. Human tempos vary naturally (slightly at least) all over the board. (If you doubt that, drop a golden oldie into a DAW and just try to adjust the grid.)
Neither "Quantize" and "Humanize" helped. Tempo changes like ritardando, accelerando, rubato are essential for the musicality of real performances. Not that the grid/click-track HAS to have any effect on any one part, but it very much complicates, e.g., automated/samples parts.
Human performances vary tempos according to feelings. This feature may be manual, but it sounds like progress.
[QUOTE follows]
"A nice sort of music would result from such playing. Something like the singing of a good vocalist accompanied by a poor blockhead who hammers away in strict time without yielding to the singer who, in sheer despair, must renounce all artistic expression." - Constantin von Sternberg (1852–1924) (c. 1920). "Tempo rubato, and other essays".
Ardour is GPLv2 open-source, but they still do somewhat pointedly attempt to dissuade you from building from source ¹).
Now, I fully understand why. And I think charging for pre-built binaries is a totally valid way to attempt to finance an open-source project. The amount they're asking certainly is a pittance compared to the commercial offerings.
LMMS is a great little program too but in much the same way that a professional mix table is less 'friendly' than a four track recorder.
Both have their uses. What bugs me about LMMS is that it is hard to use its output in any other way than just to send it to your devices, interop with other software isn't all that good unless it is on the plugin side.
And neither Ardour nor LMMS come close to midieditor for the editing of raw midi files, and that's a shame because midieditor isn't very well supported and a bit fragile (it crashes with alarming regularity).
The What's New page says they support the "Novation Launchpad Pro", but the picture beside that paragraph actually is the much more expensive "Novation Launchpad Pro [MK3]". (Ambiguous product names like this are mildly infuriating)
Does anyone know if both the cheaper and more expensive devices are compatible with Ardour 8?
Your first link is to an older version of the Launchpad Pro that Novation no longer sells or makes. The Mk3 is the current version of the Launchpad Pro.
As our release notes indicate, we hope/plan to announce support for the cheaper Launchpad X and Mini during the 8.x development process.
I definitely don't have the budget for a Mk3 but I can see a number of original Launchpad Pros and Mk2s for sale on local websites for not much money. Count me in as another person interested!
Ardour's UI is complicated compared to, for example, Ableton Live. For example, I have added a MIDI track and it is unclear how to add notes to it. Right clicking on a track doesn't give an option to do that.
Also on Linux it supports only rarely used plugin formats (LV2, Linux VST), for which there are little plugins.
I many times used Ableton ... tbh it's not less complicated then Ardour.
You can use yabridge for Win vsts ... works quite good for the most plugins IMHO but on kx.studio you find a hell lot of Linux native plugins ... don't look as fancy as commercial ones but they do what they should do.
Music production in Linux is often a bit more hackyhack but it's ok so far.
At least this are all tools ... using them is the real art behind that.
> Also on Linux it supports only rarely used plugin formats (LV2, Linux VST), for which there are little plugins.
Ardour used to have built-in support for Windows VST via WINE. It was so bad (as in unstable, unpredictable) it was disabled by default and was eventually removed. Yabridge is the usual recommendation to people who really want/need it.
> Ardour supports only Linux VST (rarely used, unpopular format).
"Linux VST" and "Windows VST" are not plugin formats. "VST" is the format, "Windows" and "Linux" are platforms. Do you seriously expect a Linux app to run Windows plugins out-of-the box?
> Most of plugins use Windows VST, i.e. they are distributed as Windows-compatible DLL.
Yes, most (commerical) plugin companies only provide Windows and macOS binaries. But how is that Ardour's fault? You can run Ardour on Windows on macOS. If you really want to use Linux and you need to use Windows-only plugins, you can either run Ardour in Wine or use a plugin bridge such as yabridge.
The link says that it supports only Fedora 38. Also, the main page for COPR says (in a small font): "NOTE: Copr is not yet officially supported by Fedora Infrastructure.". As I understand, it is the repository for packages uploaded by random anonymous users (not related to the authors of yabridge or Fedora).
That is correct. I didn't think specifically about Fedora 37; it's been a while since I upgraded to 38. I couldn't find F37 builds, even though that's around the time I tested yabridge. You might consider switching to 38 anyway, as 37 is less than two months away from it reaching EOL -- F39 release date (17 October) + 30 days.
> As I understand, it is the repository for packages uploaded by random anonymous users (not related to the authors of yabridge or Fedora).
That is mostly correct. It was not uploaded, but built on the Fedora infrastructure, following the RPM spec you can reach from the builds tab [1], for example the latest change located here [2].
There is an amount of trust you have to give to the copr author, but you can also check the rpm spec file [3]. Important quick checks are around the source0 lines.
> Also, the main page for COPR says (in a small font): "NOTE: Copr is not yet officially supported by Fedora Infrastructure."
Getting a package shipped into the Fedora base repositories seems rather bureaucratic and I understand any hacker that doesn't want to use their own time to deal with that.
I really like the UI in the sound production software. It's neat, has good colors and keep being eye candy even given the number of controls and information it provides.
Is it some sort of standardized style guide for this kind of UI or everyone just takes inspiration by some industry leader products?
FL Studio is a very, very different DAW from most others. If you get used to it, then most other DAWs are going to feel as if they are lacking something (though they will typically have something that FL Studio doesn't have, too).
It honestly does most things that these do, but I do find ableton to be a bit more intuitive. The workflow is a bit different, sessions are given more importance in ableton while the timeline feels like the __main__ way of working in ardour. The piano roll is integrated in the timeline which is a nitpick thing that I don't love about ardour. All in all, you can do basically the same things, but for some reason I do feel like it takes just a bit more work in ardour. But I'm an amateur hobbyist, so I prefer the OSS version.
I believe most plugins expose their GUI only as an X window that needs to be nested in an application window, so any change here would require reimplementing the GUI of a lot of plugins.
But even if we do want to take this hurdle, is it even possible yet? What interfaces are available to do this on Wayland and embed a plugin-drawn GUI in a GTK 3, GTK 4, Qt 5 and/or Qt 6 application?
My guess is we still need a new spec that would probably revolve around OpenGL/EGL or Vulkan/WSI, but I'm not sure, and there's also the question of how input events are delivered.
Interestingly, Presonus are now making Studio One available on Linux, and they are "wayland native". They came up with an "interesting" solution for plugins: they just create a rendering surface and have the plugins draw on that. How this deals with event handling is unclear at this time.
AFAIU Ardour itself is still using GTK 2, which has no Wayland support. You can search around on the Ardour discourse, occasionally somebody asks about the porting effort to a newer GUI toolkit, but IIRC the Ardour devs think it's too much work for little gain.
For large x64 machine we use for music, maybe not very soon. But I work on embedded devices for medical application (basically fancy iPads with other hardware) and it's already wayland only down to the drivers.
I think XWayland will be the way to go for a long time. For ardour itself, native Wayland is desirable for tooltips and other minor (but very annoying) UI things that break under XWayland, but for plugins, XWayland can be the glue.
Looks to be a extensive update with lots of new and useful features, thanks as always PaulDavisThe1st :) Especially Arrangement and Quick Groups will be good time savers for me!
> For several years, people downloading Ardour for macOS have had to deal with various kinds of messages (from Apple) saying things like "This program comes from an untrusted source" to "The file is damaged". As of Ardour 8, macOS users downloading Ardour won't see this stuff any more, because we have given up and paid $100 to join Apple's pay-to-play scheme. Our builds are all notarized now, and so people on macOS should have the same smooth experience they get from other macOS software downloads.
Hope macOS users live up to the commonly referenced "Apple users are more likely to pay for software" and donate either time or money to Ardour if they use it, as it seems making applications available to them cost developers actual money now.
I thought Ardour was a commercial product? If you want to download a binary from their site it's either a demo version with injected silence every 10 minutes, or a paid-for option (either a small monthly sub or a larger one-off payment). You can build it locally yourself for free of course, but I don't know if many non-devs would do that.
It is not really a commercial product, rather it follows an old, but somewhat rare, tradition of making usage slightly more difficult in order to raise funds. OpenBSD used to do the same and not provide pre-built images to raise funds via CD sales from those that could not be bothered to learn how to build images from the source code. You can certainly object to this, but I do find it reasonable as there are few good ways to fund open source software.
As for Ardour itself, it is clearly completely open source [1].
I don't object to it at all, I think it's a great idea. We need more models of supporting open-source, including financial ones. BTW I also don't see commercial and open-source as intrinsically opposed to each other - projects can be both, and I wish more were.
Ardour is free software (and therefore open source). Ardour is not proprietary software.
Ardour is a commercial product. They sell pre-built binaries, updates (perhaps some level of guarantee/support for those binaries?) etc. Ardour is not "freeware", shareware or a hobby project or anything else like that.
I am not sure it is clear cut as you present it. Clearly Ardour the project is not a commercial product and the same should go for the source code. Arguably the pre-compiled binaries are a commercial product as they are presented to a market for a price (although the same of course does not hold for Ardour binaries provided through package managers and elsewhere). To me, the confusion mostly arises from the fact that we use Ardour to refer to all of the above, while clearly they are all different things.
Ardour certainly looks like a commercial project to me. I think this thinking arises from a couple of misapprehensions, namely:
1. Commerce is bad and somehow at odds with free software and the GPL,
2. The only way to do any kind of software trade is proprietary software.
In fact, commerce is beautiful and a cornerstone of economics and our civilisation. Most people in the free software community are not opposed to commerce. What they are opposed to is proprietary software. That is, claiming ownership of software and therefore doing commerce based mostly on rent-seeking and retaining power over said users. Free software and the GPL aims to disable this, but it does not disable, nor does it oppose, commercial software, unless you believe (2), which is evidently false, as you can see with Ardour.
I am not sure how Ardour would feel about being referred to as a commercial project. But I do suspect if you went back in time and sent an e-mail to misc@ ten years ago calling OpenBSD a commercial project because they sold CDs you would be told to take a hike. I will just agree to disagree on this one. You seem to want to make a bigger point about software and commerce and all I see are shades of grey in that commercialisation is not clear cut and neither is what is a project, its outcomes, etc.
I think GP makes a reasonable point about what commercial actually means. If you are selling something, that's commerce. If the Ardour dev or OpenBSD devs don't like it, then they are free to adopt a euphemism that makes them feel better about it, but that appeal to authority doesn't change the meaning of the term. I think that actually further reinforces GP's point about how the term "commercial software" has become a dirty word.
Now that said, I do support avoiding language that is offensive to people even if it doesn't seem to me like it should be (so long as it's still clear what is being communicated. I don't like Orwellian expressions).
"Give your stuff away for free to devs" is a pretty good idea for both free and nonfree software. (And Linux users are, for now, still likely to be developer type people than not).
Ardour is very high quality for FOSS. There are many distros that include a free version of Ardour. Ubuntu Studio[1] for instance, and then there are distributions where installing it is an apt-get[2] or yum[3] or whatever[4] away, and paying for it is optional.
That is unrelated. Things licensed as open source can still be commercial products.
Ardour is open source and can be freely build and distributed, but it's also available as a pre-build product to pay for.
Ah I see, so that's what it looks like when you're not using a linux distro to obtain Ardour. And no, I never pressed the button because I just get it through Ubuntu Studio, and I've been using Ardour for years, for my simple (but frequent, multiple times per day) needs whatever version is in there is plenty.
I don't think macOS users have any more or less responsibility paying for this software than Linux users. $100 compared to the development resources that went into this is nothing, and the developers realised that, too.
You also need to afford a Mac machine for testing as a dev. That's another few hundred bucks on top. I don't think macOS users have a bigger responsibility for paying, but as a publisher I would always make a paid macOS version just to try to regain those expenses again. Time is not equal to money for many people
Nah, I think it's perfectly fair to charge more for a mac version of a program, especially if it's a donation funded open-source one. If you can afford a macintosh, you're more likely to also be able to afford a couple of bucks to support it.
I'd be willing to bet the demographics of those on Hackernews aren't exactly in the "I'm using Linux because I cannot afford to use any other OS" crowd.
It is the other way around. Linux users should be more vigilant about donating to the projects they find important if they care for the longevity of the project continuing as desktop Linux is a very tiny market to support and has heavy fragmentation issues within it.
Seconded. I can afford any OS but I'm using Linux out of principle. It's also - at least for me - the most seamless developer experience out there because I'm running the same OS on servers and my desktop. Whenever I have to work with Windows or a Mac I feel like a fish out of the water.
> as desktop Linux is a very tiny market to support and has heavy fragmentation issues within it.
It's also free to use and distribute software on, regardless of the hardware/software you own. That's the big difference. Plus, MacOS also commands a relatively small market share with it's own fragmentation issues (doubly so if you're cross-platform).
If Mac users want perpetual builds of their software, they have to perpetually fund a development environment. Linux doesn't really work the same way.
Yes, of course it is fair. You can charge whatever you want for your program. But Ardour is free. Accepting donations is not the same as charging for something.
OK, I see, I didn't know that. I was just clicking through to the macos download without actually downloading anything. By the way, there still seems to be a notice before download that macOS will say that the app is damaged, although now it won't complain after notarisation, right?
I actually moved away from Apple/Swift development because of the limitations they place on you even if you pay (I cannot embed an interpreter in my iOS app, really?), and am now coding in TypeScript. So while the $100 are not a big deal, I think, it's a symptom of something that's wrong.
> I don't think macOS users have any more or less responsibility paying for this software than Linux users
I don't think that either, it's only a hope from my side. A hope that they recognize that the binary they are using cost someone money to generate only because of restrictions put forward by Apple.
IMHO it should be illegal (for a for-profit corporation) to own both the OS and an application store (at least the kind featuring third-party software) - you cannot expect them to be a fair judge of who gets in there and who doesn't !
You can still run the software, but Apple make it harder to do so (you probably have to Google how to do it). You could argue this both ways, I think there's value to the defaults making it harder for your average user to run software which could be unsafe... just think how bad the malware problem used to be on Windows for example.
The malware problem used to be bad on Windows because everything had admin access. And the later "we don't have this program in our database, do you still want to execute it?" dialog wasn't too bad (especially when paired with an integrated blacklist of known malware !).
And why do you assume that other software distributors than OS makers aren't going to do due diligence ?
100 USD a year (more in Switzerland because Apple doesn't even pay for the taxes) is not nothing. Why should I pay to place apps that I spend my free time to develop and offer for free? Apple should at least not charge a recurring fee if all apps posted are open source and free.
I'd also prefer if there was no $100 to pay. But it is a fair price, and I find the attitude of programmers that everything should be free quite damaging. If you want to donate your free time, that's really up to you. Don't construe constraints for other people or companies from that.
I don't recall the exact message, but I don't think they say it is damaged. They will probably say something like it may be damaged. Which is perfectly true, as they have no means of verifying its integrity.
They didn't do that for the Windows version though:
> Because we object to paying Microsoft for the privilege of allowing you to more easily use our work, this application is unsigned (more information here).
We will likely start doing Windows notarization during the 8.x series. Our friends at Harrison, who make Mixbus (based on Ardour) already figured it all out a long time ago; it's a bit more complex than the macOS version of the process.
The message is a little confused--Microsoft never charged for code signing. You don't pay Microsoft. You have to get a code signing certificate from a third party CA; you choose your favorite. Microsoft themselves doesn't offer them.
This is different than notarization. Notarization is a process by which Apple centrally scans your binary and decides if it's ok, then stamps their approval on the binary if so. Code signing is a process by which you sign your own binary so that users (and, more importantly, Windows) know it's from you.
Microsoft doesn't do notarization, instead relying on the reputation of the certificate and their client-side malware scanner. The reputation from one executable you sign with the certificate carries over to other executables that you sign with the same certificate (e.g. newer versions of the same app). This impacts SmartScreen prompts. If you get an EV certificate you get the initial reputation for free and can skip SmartScreen prompts out of the gate.
source: have done it; my open source Windows app is signed with my Sectigo certificate
> Hope macOS users live up to the commonly referenced "Apple users are more likely to pay for software" and donate either time or money to Ardour if they use it, as it seems making applications available to them cost developers actual money now.
Just make it $5 on macos. If Mac users can support this shitty company they can actually pay for other software too.
Maybe it's a bit off topic, but I think there is something on the website we can all take a note of: that is, on the download page, it says download "Ready-To-Run Program".
Yep, not download "Binary", "Executable", "Package" or any of that non-sense (from user's perspective), just "Ready-To-Run Program", simple and clear, exactly what user wants when they open that page.
Have you tried clicking it? It takes you to a 2nd page where you select the OS.
Then for me (Windows) to yet a 3rd page where I can chose the paid/free version.
Clicking here on "Demo Version" takes you to the 4th page where you can finally download the setup binary. Which is an installer, the opposite of "Ready-To-Run"!!!
But to get "Just download and run Ardour on your Linux, macOS or Windows computer." I have to click Ready-to-Run Program -> Download Ardour 8.0 for Windows 64 bit -> Download Demo -> Download Ardour 8.0 for Windows 64 bit (Demo)
Each on a separate page, a little bit misleading because the first button already suggests a download
When we put it all on one page, too many people failed to understand the process. We can please some of the people all the time, but we can't please all the people all the time.
"Some people will no doubt laugh at a few of these "new features", given that they've been in some other DAWs for 20 years or more. That's OK — we laugh too when we see other DAWs finally adding things that Ardour could do in 2005."
this made me laugh :-)