Hacker News Reader

Comment by backlash875 | Hacker News Reader

I've tried using it but it crashes too often and is generally too buggy to use. It seems to be in an early stage of development so this is to be expected. The UI and general workflow look very promising though, in particular the piano roll. It has a long way to go to match the maturity and features of Ardour, but the UI design that it's aiming for will make it more suitable for people making EDM.

View on HN

It's using some notable chunks of Ardour's code, which might help it along.

OTOH, Reaper's lead developer was thinking of doing that at the beginning of Reaper's life, decided against it, and we can see how (well) that worked out! :)

Please elaborate, not sure if you mean in a positive or negative way.

For what it's worth, I find Reaper to be a lot better than Ardour in general. It just feels 100% professional and slick. The Ardour interface comes across like your typical GTK app, sluggish and glitchy with that constant feeling that something ain't right. You should have moved to QT a long time ago.

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.

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).

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!

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.

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).

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"

not just code, even the price model and some bits here and there from Ardour's website and other ideas. I'm really thankful for Ardour for paving the way, and Robin Gareus has been key to getting this far with his advice and help

Reply on news.ycombinator.com