Re: [linux-audio-dev] matrix model vs. memory

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

Subject: Re: [linux-audio-dev] matrix model vs. memory
From: Jörn Nettingsmeier (nettings_AT_folkwang-hochschule.de)
Date: Mon May 21 2001 - 12:03:36 EEST


Abramo Bagnara wrote:
>
> Tom Pincince wrote:
> >
> > > Yes, but I don't have excluded the possibility to have buffer sharing.
> > > Of course this is feasible only for a subclass of static gain matrix.
> >
> > It may be useful to consider the percentage of connections that are
> > static gain. If this number is very small then the efficiency loss is
> > worth the simplicity of having only one kind of connection. In
> > situations where the user is using just a simple app, such as for
> > playback, the efficiency may go down by a large percentage, but the
> > total demand on the system is so low in this case that preserving
> > efficiency is not an issue. So if we look at a complex studio setup,
>
> Don't try to use a crystal ball when designing an API. It's dangerous
> and I'm sure to be able to find a counter example for each imposed
> limitation. (And I'm also sure that to tell you them is perfectly
> useless).
>
> What we need to do is a complete API with no efficiency drawbacks and no
> needless complexity.
>
> To have something that work well for an application subset, but it's not
> appropriate for another is a symptom of bad design.

abramo,
might this be yet another incarnation of the age-old "make it work,
then make it better" vs. "make it better first" battle ?

btw, i think it's not very sensible to accuse a studio tech like tom
of "looking into a crystal ball" when he gives a concise analysis of
signal flow and gain handling in an *actual* studio.

i might be missing a point here, but i'd rather have a limited api
*today* than a perfect api in the future, where

  lim(release date) = never
  (perfection -> oo)

while you can always construct scenarios that call for yet another
generalization, the motor of open source has been the need to
scratch an itch (= solve an existing problem), not the quest to
boldly find itches that no man has ever felt the need to scratch
before.

imagine the computer composers and supercollider fans join in and
propose a gazillion of other control interactions between
components. this whole api might just never take off.

jörn

-- 
Jörn Nettingsmeier     
home://Kurfürstenstr.49.45138.Essen.Germany      
phone://+49.201.491621
http://icem-www.folkwang-hochschule.de/~nettings/
http://www.linuxdj.com/audio/lad/


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

This archive was generated by hypermail 2b28 : Mon May 21 2001 - 12:20:25 EEST