[Ardour-Users] Struggling to do anything at all

[Paul Davis]

On Thu, 2007-08-02 at 16:28 +0100, Steven Chamberlain wrote:
> 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, 

i've been in a couple of situations that used unit testing. to be
worthwhile, unit testing needs to be done by someone other than the
developer of the original code. if someone steps up to write/generate
such a framework for ardour's codebase, i'd be happy to consider it.
until then, its very very far from the top of any priority list that the
existing (small) developer community has.

> to functional tests
> putting Ardour through the full workflow and verifying the result.

thats exceedingly hard to do. ardour is fundamentally a graphical
program and has not been written (so far) to be controlled by a script.
writing even a written description of a "full workflow" test is a huge
effort, and doing the test is a full day or more of work, everytime its
done. this is why we currently rely on "distributed debugging", in which
a larger number of people actually use the program in their own
different ways, and report back on issues they discover.

> Equally I feel 'guilty' when I can't get anything done in Ardour and
> have to report one problem after the next. 

never feel guilty about that.

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

once you get good at it and have years of experience, its not harder
than anything else but the tools can be different. single-stepping
through a realtime thread to try to pin down a race condition, for
example, is not useful.

> Maybe null audio or disk drivers for a start (does Ardour have these?
> JACK does, but it still disconnects ardbg when using them);

jack never disconnects ardbg for me if i run jackd in non-realtime mode.
i use this approach a *lot*.

> 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?

well, we can't really suggest a workaround until we know precisely what
steps you are taking that lead to the crashes and issues you have. read
below for an example of a very similar issue as your #3, discussed
within the last hour or so on IRC:


Aug 02 10:45:05 <peppo>	ardour: [ERROR]: Session: XMLNode describing a
AudioRegion references an unknown source id =10289
Aug 02 10:45:05 <peppo>	ardour: [FATAL]: programming error: unknown
region type passed to Session::add_region()
Aug 02 10:45:09 <peppo>	on a working session
Aug 02 10:45:39 <peppo>	I saved a session, quit, and tried to restart
Aug 02 10:45:40 <peppo>	and get this
Aug 02 10:45:41 <peppo>	2.0.5
Aug 02 10:46:10 <peppo>
http://senap.kicks-ass.net:8088/20070802kmo.ardour
Aug 02 10:47:04 <peppo>	same in .bak
Aug 02 10:48:40 <peppo>	sampo_v2, can I remove the region entry? I
really need to get this session working again... have people waiting to
lay vocals
Aug 02 10:48:53 <las>	peppo: you can
Aug 02 10:49:28 <las>	sampo_v2: here's the odd thing
Aug 02 10:49:59 <las>	sampo_v2: the regions using that source ... they
are stereo but the ID's of the sources are 10289 and 10291
Aug 02 10:50:13 <las>	sampo_v2: i'm not sure i would expect them to be 3
apart, i guess its possible
Aug 02 10:50:43 <las>	peppo: do you remember these regions, called ref1
and ref2 ?
Aug 02 10:50:52 <peppo>	they are imported hydrogen exports
Aug 02 10:50:57 <las>	sampo_v2: no, the files are two distinct objects
Aug 02 10:51:19 <peppo>	there were issues when dragging ref2 to the
timeline
Aug 02 10:51:22 <peppo>	it wouldn't import
Aug 02 10:51:32 <peppo>	so I removed the source file and reexported and
reimported
Aug 02 10:51:44 <las>	peppo: how did you remove it?
Aug 02 10:51:59 <peppo>	regions: click ref2: Remove in context menu
Aug 02 10:53:30 <las>	peppo: incredibly useful info
Aug 02 10:53:48 <las>	peppo: what were the problems with importing it?
Aug 02 10:54:46 <peppo>	no idea, nothing visual
Aug 02 10:54:57 <peppo>	but it just wouldn't add it to the editor
Aug 02 10:55:02 <peppo>	ehm, to the track that is
Aug 02 10:56:33 <las>	peppo: you were importing "To track" ?
Aug 02 10:56:43 <peppo>	no, in the Regions tab
Aug 02 10:56:46 <peppo>	Add external audio
Aug 02 10:59:25 <las>	peppo: did it work the 2nd time?
Aug 02 10:59:47 <peppo>	after the reexport
Aug 02 10:59:51 <peppo>	there was something fishy about the file
Aug 02 10:59:54 <peppo>	possibly it was empty
Aug 02 11:00:40 <las>	peppo: meanwhile, you had dragged ref1 + ref2 to
the "Trumma 2" track?
Aug 02 11:00:55 <peppo>	ref1 was on trumma 1
Aug 02 11:01:00 <peppo>	ref2 was for trumma 2
Aug 02 11:01:26 <las>	peppo: right. so you had dragged the regions
there?
Aug 02 11:01:30 <peppo>	yep
Aug 02 11:01:50 <las>	peppo: after the 1st (failed) import, or the 2nd ?
(sorry, i think i know the answer but i need to check)
Aug 02 11:03:12 <peppo>	I dragged to the track from Regions the first
export... nothing happened
Aug 02 11:03:20 <peppo>	so I reexported from hydrogen as another
filename, then imported to ardour
Aug 02 11:03:26 <peppo>	THEN it would let me drag to the track
Aug 02 11:06:27 <las>	peppo: so you imported, got something in the
region list. tried to drag. it failed. you removed it using the context
menu. then reimported and dragged again. is that the whole story?
Aug 02 11:06:52 <peppo>	las, yup. but wha I reimported was a new file
from hydrogen
Aug 02 11:06:59 <las>	peppo: understood
Aug 02 11:07:25 <las>	peppo: could you paste an ls of the soundfile dir
for that session ?
Aug 02 11:09:07 <peppo>	las, http://rafb.net/p/nAyC2g86.html
Aug 02 11:11:26 <las>	peppo: are ref1 and ref2 likely to be the new or
old versions of the h20 file?
Aug 02 11:27:06 <peppo>	las, no. ref1 had no problems... it worked nice
Aug 02 11:27:34 <peppo>	ref2 is the drum export which failed. refapa is
the new attempt an export, and it worked fine within ardour
Aug 02 11:28:23 <las>	peppo: ok, so it looks as if the removal of the
regions from the list did not remove the sources then.

notice how this discussion isolates and pinpoints precisely what
happened, and allows me to jump right into debugging and testing. this
is critical when we face problem reports about problems that we haven't
seen in our own testing/work.

> 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?

very, very silly. what are you trying to record, and what are you goign
to do with it after you're done?

--p