[ardour-dev] Development environment
mike.taht at gmail.com
Mon Apr 9 06:12:11 PDT 2007
On 4/9/07, John Emmas <johne53 at tiscali.co.uk> wrote:
> ----- Original Message -----
> From: "Kjetil S. Matheussen" <k.s.matheussen at notam02.no
> > But after a while, you'll discover that its actually "Do it the most
> > efficient way possible".
> Hmmm - we'll have to agree to differ on that one..!!
Incidentally, I use emacs (compiled from the unicode branch) + ecb, the
emacs code browser, to cope with the depth and complexity of the Ardour
source. ( see http://ecb.sourceforge.net). It's still not as pretty as
eclipse, but it has incredible depth, and runs quite fast compared to
eclipse. Notably, emacs + ecb is a lot more reliable than eclipse on x86_64
I often think that if 1/1000th all the resources sunk into eclipse had been
sunk into emacs instead it would be a far better world.
Actually though, this brings up a more serious question... where I intended
> to start was by stepping through the Ardour code to see what happens when
> an Ardour session gets saved. I'm used to doing that sort of thing from
> within my development IDE. What's the equivalent procedure if there's
> no IDE available?
Ardour is a realtime process with many threads. It's almost impossible to
"step through" anything as there is so much going on at any given point,
that (for example) if you stop one thread another thread will error out and
the whole program exit. You need to be running jack in a non-realtime mode
with a huge number of periods in order to even slightly be able to
single-step for brief periods.
So I tend to resort to "printf debugging", writing gdb scripts that trap,
execute a display routine, and return, and introspection via (for example)
oprofiling the code, rather than single stepping,
> ardour-dev mailing list
> ardour-dev at lists.ardour.org
PostCards From the Bleeding Edge
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ardour-Dev