Re: Using GCC for "real-time" compilation in audio engine development

[Jan-Benedict Glaw <jbglaw at lug-owl dot de>]

On Wed, 2002-12-04 17:33:12 +0100, Torgeir Strand Henriksen <torgshen@stud.iet.hist.no>
wrote in message <1039019592.368.37.camel@blucher>:
> > The concept is like
> > what transcode (for video + audio), alsaplayer, netscape, XFree and
> > other applications do: compile each functionality (an input filter for
> > .wav, an input filter for reading from sound card, effect filters,
> > output filters, ...) into an object file and build a central application
> > which does no more than loading appropriate plugins and feds the data
> > through it. This is done with dlopen(), dlsym() and dlclose().
> 
> Yes and no. While you could think of this as an input -> plugin ->
> output situation, the program isn't meant to load readymade audio engine
> plugins written in some programming language, but *create* the code
> based on a graphically editable structure. A screenshot of a commercial
> program with this kind of user interface (though it apparently traverses
> the structure rather than compiling it to native code, if the lack of
> speed is any indication), can be found here:
> 
> http://www.sospubs.co.uk/sos/oct99/images/reaktor5.gif

Even this does look like a pile of modules, whose input parameters can
be specified through some nice frontend...

> One could of course make a boatload of plugins that can be loaded and
> connected to eachother (similar to Buzz or VST for those who are
> familiar with those, only lower level), but this would waste plenty of
> cpu cycles. Calling a plugin function that adds two samples together is
> a lot slower than simply adding them. It could be argued that by adding

I can't see it this way. If you've got to add two streams, you'll call
some function to do this. The only real overhead plugins take with them
is the time you need during linking them. If you load a lot of them,
you'll possibly reach something as long as one second, but after the
modules are mapped, they're ment to behave exactly the same as if you'd
place the functions directly into the binary...

> two arrays of samples rather than just two samples, the plugin wouldn't
> waste that many cycles, but then customizable feedback loops (used in
> operations depending on previous samples, e.g IIR filters) becomes
> impossible. As far as I can see, plugins wouldn't be useful, except for
> the various code generation back-ends.

Hmmm... Seems I still didn't get it right:-(

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur
    fuer einen Freien Staat voll Freier Bürger" | im Internet!
   Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/

Attachment: msg00183/pgp00000.pgp
Description: PGP signature