[PaulDavisThe1st]

Reaper is a great application.

I don't bother to listen (much) to critiques of Ardour's GUI. Every week I get an email that tells me it is totally pile of crap and I should feel embarrassed to even consider it usable, and another telling me how smooth and intuitive it is, much better than any other DAW.

When people say things like "Ardour's workflow for doing <X> is a bit clunky - it takes 6 mouse clicks, but if you did it like <this> it would only take 3" ... I try to listen to that and incorporate these kinds of ideas.

Reaper does a bunch of things that Ardour doesn't. Ardour does a bunch of things that Reaper doesn't. Reaper does some things that we both do better than Ardour, and vice versa.

"300k+ LOC application should have moved to <other GUI toolkit a long time ago" suggests that you have never moved 175k lines of GUI code between toolkits, regardless of which application and which toolkit you're discussing.

Also, Reaper doesn't use Qt.

[msoloviev]

I actually like Ardour's GUI a lot (and am grateful that it uses Gtk: KDE never ran stably on a machine I owned, and I found that in Gtk-based environments, it is actually always the Qt applications that are inexplicably unstable). The main problem that prevents me from using it is that I keep running into show-stopping bugs in the backend: for instance, MIDI recording (including even "loopback" where I just recorded the output of another MIDI automation channel playing in Ardour itself) in 5.12 kept dropping note-on/-off events, and more critically, there is some persistent issue that results in ZynAddSubFX plugin settings getting corrupted through save-load cycles. I have confirmed that the latter is still around in 6.0, and the furthest I have gotten in pinning it down is the observation that the correct state seems to get saved in a plugins/<id>/state<n> folder, but this is not what gets loaded and loading and then saving again without doing anything else results in it creating a state<n+1> subfolder with the garbled state without state<n> being touched.

I haven't had any luck getting responses to bug reports, and anyhow it seems that ZynAddSubFX should be a sufficiently common plugin that if this bug were easy to reproduce, someone else would have stumbled upon it by now (and so it probably arises due to a weird interaction with something else that's particular to my setup).

[PaulDavisThe1st]

The lead dev of current zyn says: " I heard about the corruption issue quite a while ago, though I had thought it was traced back to a now resolved DPF issue. I might be wrong about that though"

[megameter]

My half-remembered experience of Ardour from some years back was that it felt very fleshed out in replicating traditional recording, but had little in terms of sequencing. As such it was "wonderful product, just not for me". And I'm happy to hear that you are sticking with it.

I have basically stuck with OpenMPT after all this time, since most of the time I want to really sequence something on the grid, and only deviate from that if really necessary(and then usually turn to Mixcraft which has a decent set of defaults and built-in plugins and presets for most things).

[PaulDavisThe1st]

Yeah, Ardour definitely started life as linear/timeline recording tool, along the lines of (then) ProTools/Samplitude/Pyramix/Sequoia.

Ableton Live changed everything, even for the sequencer-originated DAWs like Cubase, and it's true that in Ardour we haven't (yet) attempted to tackle that sort of thing.

Stay tuned though!

[grawprog]

Personally I prefer the lack of a sequencer in ardour. I use muse or rosegarden for most midi tracks and hydrogen for drums. I feel like this fits more with the modular linux philosophy, though I do realize ardour is cross platform. I appreciate that ardour has pretty much one paradigm and does it well.