I'm Ardour's original developer and I'm happy to answer any questions anyone may have about the release.
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.
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.
One major feature that gtk3+ (or SDL2) brings is Wayland compatibility.
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.
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).
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 :)
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.
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.
[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. ]
what was your motivation to start this project?
how do you use ardour yourself?
do you have any music to share ?
I don't use Ardour much myself. When I make music, I mostly use the amazing VCV Rack or its slightly-more-FLOSS fork, Cardinal
As for music, not really but last December I did release this: https://pauldavismusic.bandcamp.com/album/suspended-generati...