Subject: Re: [linux-audio-dev] Anyone planned a GTK2-based Multitracker?
From: Jan Depner (eviltwin69_AT_cableone.net)
Date: Sat Apr 10 2004 - 20:21:35 EEST
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
This archive was generated by hypermail 2b28 : Sat Apr 10 2004 - 20:18:41 EEST