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

[Torgeir Strand Henriksen <torgshen at stud dot iet dot hist dot no>]

> 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().

[snip]

> Or did I get you wrong?

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

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
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.

Hope that cleared things up a little. :)

Best regards
Torgeir