[Ardour-Users] Struggling to do anything at all

[Steven Chamberlain]

Paul Davis wrote:
> ardour is a huge program with many, many different
> possible workflows. clearly, the core developers cannot test every
> possible workflow

Just a thought, but perhaps an automated framework for testing is the
best way to tackle that.  I don't think Ardour has anything like this
right now.  I like the idea of automated tests, from small unit tests of
functions and classes as used by Perl modules, to functional tests
putting Ardour through the full workflow and verifying the result.
These are useful both to developers, wanting to check whether they
successfully fixed a bug, or checking their changes haven't broken
anything else; and to end-users wanting to see if/why something is
broken on their machine.

Admittedly this in itself would only be another 'new feature' which
would take more effort than it seems worth, to implement it.  And then
its implementation would probably cripple from some time, things that
were previously working.  This kind of thing is probably easiest to have
in place from the beginning.

> indeed. i am very alarmed and disappointed (in myself) by the small rush
> of people all saying "yeah, its totally unusable for me"

Equally I feel 'guilty' when I can't get anything done in Ardour and
have to report one problem after the next.  I don't want it to seem like
Ardour isn't as powerful, versatile and even reliable as it probably is
for many people.

> since ardour has (a) lots of threads (b) runs realtime in
> at least one of its threads, this puts limits on what you can do with
> debugging. this isn't a limitation of ardour's codebase, its a
> limitation of any multithreaded, realtime application.

Maybe this is one of Ardour's critical weaknesses.  In any programming
of my own, I'm very cautious about doing anything which makes the
program harder to debug.  Bugs will tend to show up in those places that
are hardest to debug.  I've not done any serious multithreading myself
but I imagine it's a nightmare to debug.

Maybe null audio or disk drivers for a start (does Ardour have these?
JACK does, but it still disconnects ardbg when using them); a lot of
problems I've mentioned about basic edit operations don't require any
real audio output.  I've always found JACK apps. very hard to debug
because of the realtime callbacks, and it would be nice to 'turn them
off' at times.

Any thoughts on what I should do right now?  I can continue to report
bugs, test patches or try to reproduce bugs reported by others.  In the
meantime I still need to try and meet a deadline for recording.  Can
anyone suggest a workaround, perhaps different software entirely if I
have to, like ecasound writing to disk, Audacity (which also seems to be
getting quite buggy IMHO) or Traverso which I've not yet tried?

Probably a daft idea, but should I try and make my own (small?) program
from scratch to do recording in the specific way I'm wanting to?  This
process of 'reinvention' seems to happen often in Linux Audio dev. but
is it ever worthwhile?

Thanks,
-- 
Steven Chamberlain
steven at pyro.eu.org