[linux-audio-dev] Re: Writing LADSPA plugins in high level language?

[Alfons Adriaensen]

On Thu, Jun 15, 2006 at 08:53:11AM -0400, Paul Davis wrote:

> On Thu, 2006-06-15 at 16:32 +0900, David Cournapeau wrote:
> > I am in no way as experienced as most people on this list for audio
> > programming, but I don't see why C/C++ should be the only way to write
> > software to handle audio stream, neither do I see why GC would be the
> > only useful feature. For example, having language constructs to
> > explicitely handle "time line" sounds like a good idea to me, and it
> > looks like both Faust and chuck enable that.
> 
> there is no universal agreement on how such features should work. if you
> provide a "language" in which this is possible, you're really providing
> an application (such as supercollider). 
> 
> a some builtin language idea about what a playlist looks like ? there
> are many variants on the idea of a playlist, and i don't think you can
> usefully provide abstract building blocks (which is what a language is
> for) and support all the variations without compromising at least one of
> those goals. 
> 
> faust, btw, has no concept of a timeline in the sense that chuck does.

The bottom line here is that this sort of thing is dictated by the system,
or by interfaces close to it such as JACK. And you better do thing the way
the system expects you to, unless you are prepared to accept intermediate
layers that add overhead and latency.

One could in theory contruct a language that knows the concept of a 
'period' of frames, and that allows you to write audio code and be
oblivious of the fact that is in fact processed in chunks of N frames,
that you have to maintain state between callbacks, etc. But you can
only hide these things up to a certain point. When you write some
code that maps badly onto the current period size, then either it
will be be very inefficient, have horrible latency, or the language
will just fail. So the result would be that the language becomes the
thing that determines what sort of functionality can be programmed
and what can't, and in that sense it has indeed become an 'application'
rather than a language: it only allows you to do those things that
were envisaged by its designer.

There is a similar situation with multithreading. ADA is one of the
few languages that supports it natively, and most early ADA compilers
had their own implementation.  But if you want your ADA tasks to
interact in a natural way with the surrounding system, then you have
to use the system's concept of what a thread is (i.e. construct the
ADA tasks on top of NPTL), and it's near impossible to do this without
either exposing somehow the underlying system to the user, or limiting
the functionality.


-- 
FA

Follie! Follie! Delirio vano e' questo!