[linux-audio-dev] Anyone planned a GTK2-based Multitracker?

[Jan Depner]

On Sat, 2004-04-10 at 11:08, Kjetil Svalastog Matheussen wrote:
> 
> Jan Depner:
> > > Why on earth use C++? Use a desent high-level non-crippled language like
> > > lisp, python or ruby. The lowlevel stuff must of course be written in
> > > c/c++ or something, but only a very small amount of multitracker-code is
> > > that low-level. Yes, I have made _huge_ programs in C myself, but that was
> > > only because I was so damned inexperienced and had so damned slow machine
> > > to work on at the time.
> > >
> > > Today, where there are so many descent libraries for
> > > lisp/python/ruby/ada(?)/etc(?), and the machines are so fast,
> > > as good as no one should use c++ for high-level things. You'll
> > > waste time.
> > >
> > > Yes, this might start a flame-war, but I really think people
> > > should be aware of the C/C++-stupidness.
> > >
> >
> >
> > 	Audio is inherently computationally intensive.  So your answer to those
> > who have slower machines is "buy better hardware because I don't want to
> > bother writing in a language that is fast enough to work on your
> > system"?  This isn't a flame it's just that I don't understand why you
> > consider C/C++ stupid.  They have their place.  I work on scientific
> > applications and I guess I could use Perl or Python or (shudder) MATLAB
> > (if you can consider that a language) but I don't because they're too
> > slow.  Where I work we have a supercomputer (currently at #18 on the top
> > 500) and we have applications coded in (again, shudder) FORTRAN.  Why?
> > Because it's faster than C or C++ on supercomputers.  It's better at
> > parallel processing.  I did FORTRAN programming for 14 years before I
> > switched to C (yes, I'm _that_ old).  I've also programmed in COBOL,
> > BASIC, three or four different assembly languages, Pascal, Java, you
> > name it.  They all have their place.  I just don't get this "my language
> > is better than your language" stuff (with the possible exception of ADA
> > ;-)
> >
> 
> Thats not what I said. Or ment at least. I said; use a high-level language
> for high-level operations. I'm not saying: Do computer-intensive/realtime
> critical operations with lisp/python/ruby/etc. Ardour consist of about
> 90% GUI code, if I have understood correctly. Those 90% of code could
> have been written in a more high-level language with garbage collectors,
> proper list-functions, dynamic typing and other helpful things c++ does
> not provide because C++ is supposed to be extremely fast, allways.
> Or in case not, why not?
> 
> -- 

	Ah, good point.  However, the SLab GUI is written in Tcl/Tk and it just
doesn't cut it because the GUI can't keep up.  It's _very_ nice but
extremely limited.  Granted, Tcl/Tk is not Python but you get the idea. 
I have run a few experiments with Ardour.  The most interesting being to
record 8 tracks at 24/96 on my system with the GUI being local and
remote.  I use blackbox and cut the graphics overhead to the bare
minimum.  When I run locally I get a few xruns.  When I run with a
remote GUI (X windows, 100Mb ethernet) I get no xruns.  The graphics
overhead that is offloaded to the other X server has a huge impact on
the recording.  The problem that you aren't addressing is that the GUI
uses up a significant portion of the computational resources.  You want
everything on your system to run as fast as possible, not just the
"critical operations".  Take a look at how much of the system is used by
the GUI in JAMin for instance.

Jan