MNLib, RE: [linux-audio-dev] Newby(t)e

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

Subject: MNLib, RE: [linux-audio-dev] Newby(t)e
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: ti marras 23 1999 - 21:49:51 EST


Hmm. Time I spoke up and made myself and an audio processing library
(MNLib) a little more visible among the Linux audio community. Also, if
people are agreeing a way of interfacing audio programs with one another
I'd be VERY interested in contributing to the discussion because of my own
developments.

Maybe I should release some of the internal specs for MNLib soon - there's
some background at http://www.muse.demon.co.uk/mn_index.html and a number
of programs built with it, but the library itself is still rather concealed
from view. Internally there are echoes of systems like Csound or Max but
with a more generalised but potentially more efficient approach. Ideas
currently implemented include latency, feedback, configurability, grouping,
modularity, persistence, a number of mechanisms for automated data exchange
and much more. The engine is built to run real-time and some aspects of the
optimisation approach taken can only be described as brutal. Next step is
to write a generic server wrapper and a small GUI (probably Java) to allow
a Max-like interface to the system.

I've not written too many processing classes for the system yet and about
half of these relate to acoustic space modelling, though there are some
nice Z-plane sidelines. FFT is probably next - it's taken me a while to
find a model that feels right but I think I'm there. It would probably not
be hard to convert Max patches and packages for MNLib too - that could be
fun. Eventually writing audio/MIDI sequencers shouldn't be too hard working
with a Java applet (or suchlike) linking to a MNLib server. I'm hanging on
to the source code for the moment as I'd like at least to get a paper or
two out of the years of work I've put into this, but there will probably be
enough of a public API to write client apps for the server.

I've not publicised MNLib much before because I'm not into pushing
vapourware, however I've been on a 'sabbatical' from work for the past
seven months and a lot of that time has been spent composing and sorting
out issues with MNLib. Over the past couple of weeks there have been some
fundamental breakthroughs (internal and quite separate from my work with
Ambisonics) so the whole project is suddenly very real.

Ideas & thoughts more than welcome,

(Oh incidentally, I'm using single precision floats except for sensitive
calculations such as matrix maths. I'd have thought use of doubles for
general signal processing would be rather costly?)

-- Richard

-----Original Message-----
From: David Olofson [SMTP:audiality_AT_swipnet.se]
Sent: Wednesday, November 24, 1999 1:12 AM
To: cafu; lad
Subject: Re: [linux-audio-dev] Newby(t)e

On Tue, 23 Nov 1999, cafu wrote:
> 1) were can I find FAQ for this list?

Um, is there one, actually?

> 2) Since I'm starting a new project in C, i wanted to know wich type are
> best suited for audio DSP under linux ... longint, float ??? wich one do
> U use for your project???

Float for the intermediate buffers and double for the internal
calculations in plugins is more or less standard for native
processing these days. You don't want to mess with integer/fixed
point processing unless you have no alternative. Also, FPUs are
very fast already, and then there are the new SIMD instruction
sets... (KNI, 3DNow!,...)

> 3) I'm gonna to implement a DirecX-like plugins system on a Audio App...
> is already something like this out there ?? I haven't still see
> anything but if I'm really the first one thinking about it.... i would
> really need your help...

We're working on it! :-)

It's called MuCoS (the Multimedia Communication System) until we find
a better name, and I was supposed to have had the site up already.
However, everything got in the way as usual...

Basically, it's a plugin API similar to VST, but cleaner, and built
around an event system (timestamped events, somewhat similar to those
of VST 2.0). Large parts of that API will also be used for an
interprocess communication system, allowing applications to connect
to each other and to dedicated engine daemons, and even to plugins
inside other applications.

The API itself will not depend on any existing standards or OS
subsystems, so it'll be no problem building plugin hosts for other
environments, or even as a Linux kernel module - perhaps using
RTLinux for timing in the ?s range. (That's where I started, before
the excellent lowlatency patch by Ingo Molnar... :-)

Working on MuCoS:

  Paul Barton-Davis <pbd_AT_op.net>
        * An engine implementation, doubling as plugin API testbed.
        * Quasimodo and some other applications.

  David Olofson <audiality_AT_swipnet.se> (Me, that is.)
        * Another engine; a softsynth with some effects,
          meant primarily as a prototype.
        * The MuCoS web site and documentation.

  Benno Senoner <sbenno_AT_gardena.net>
        * Client/server implementation and API.
        * Various performance testing tools.
        * Some demonstration/proof-of-concept programs.

  Anyone else? (No specs released yet...)

//David

 .A.U.D.I.A.L.I.T.Y. P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
    .Rock Solid David Olofson:
    .Low Latency www.angelfire.com/or/audiality .Audio Hacker
    .Plug-Ins audiality_AT_swipnet.se .Linux Advocate
    .Open Source .Singer/Composer


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

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:25 EST