Re: [linux-audio-dev] Reverbs... and the usual whinings

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Reverbs... and the usual whinings
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Sat Sep 23 2000 - 19:01:48 EEST


>If Ardour supports 2 channels now, I could give a try.

it will support 2 tracks *and* direct-burn-to-CD by the end of next
weekend. i'm sure that not every kink will be out of the

>>did you try snd ?
>
>I could not compile it... I have Debian Slink from last fall.

why not just get bill's pre-compiled binary ?

>> pipe(2)
>> "struct foo { .... format of message ... }"
>> {write,read} (pipe[{1,0}], &a_foo, sizeof (foo));
>
>My problem is not at this basic level. The problem is how to make
>a message path to child's child or between cousins, and so on.

   * shared memory message area
   * kill (SIGXXX, pid);
   * sigaction(2)/signal(2)

or use pthreads and mutexes to accomplish message passing, which
actually uses the above mentioned method (shm excluded, since the VM
space is shared automatically).

>I just have never programmed with C++. Nothing to do with liking and
>disliking. Sure C++ has advanced features but nothing which makes it
>impossible to implement a HDR or such. Well, you tell me and I will switch
>over!

nothing to do with it being impossible to implement anything. it has
more to do with the flexibility and ease of making sweeping changes
without worrying about side-effects.

for example, i am in the middle of altering some of the inheritance
relationships in ardour so that i can have an object called
"TwoTrackTape". the internal behaviour of this object is very
different than a "MultiTrackTape" because the disk bandwidth
requirements are much lower. however, both these objects will derive
from a common object which will both provide some common functionality
and impose requirements for methods that they must both provide.

however, despite all these changes, the objects that interact with a
MultiTrackTape currently will need no alterations because i know that
there is no change to the public (visible) interface to that object.

you can do this kind of inheritance on C (GTK+ does so), but to my
taste its horrendous. compare, for example, what happens if you want
to derive a new class from say, GtkDrawingArea, in C or C++. In C++,
its typically a few lines to add the modified methods because the
compiler takes care of the rest. in C, well .... see the GTK source
code!

but its not that important - i don't want to start a language war. i
programmed in C for about 9 years before switching to C++, and i find
that for *system design* (which is important in most programs more
than 200 lines long), C++ makes my programming much easier.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Sep 23 2000 - 19:37:06 EEST