14 Jun
2006
14 Jun
'06
5:23 p.m.
Phil Frost:
Subject: Re: [linux-audio-dev] Writing LADSPA plugins
in high level
language?
To: The Linux Audio Developers' Mailing List
<linux-audio-dev(a)music.columbia.edu>
Message-ID: <20060614132522.GA3483(a)unununium.org>
Content-Type: text/plain; charset=us-ascii
On Wed, Jun 14, 2006 at 07:47:36AM +0200, Alex Polite wrote:
The realtime extension for snd (scheme-like language) is another:
http://www.notam02.no/arkiv/doc/snd-rt/
Here is a cool alsa softsynth written in that system:
http://ccrma.stanford.edu/~kjetil/220c/
Hi there.
Is it possible to write LADSPA plugins in anything but C/C++? I prefer
perl, ruby or python.
alex
Anything but C/C++, yes. See FAUST [1], a compiled language designed
specificly for processing audio streams. Perl, Ruby, or Python, not
really.
[1] <http://faudiostream.sourceforge.net/> 
15 Jun
15 Jun
3:32 a.m.
New subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language?
On 6/15/06, Kjetil S. Matheussen <kjetil(a)ccrma.stanford.edu> wrote:
Phil Frost:
there is also chuck, that nobody has
mentionned, I think :
http://soundlab.cs.princeton.edu/research/chuck/
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.
David
Subject: Re: [linux-audio-dev] Writing LADSPA
plugins in high level
language?
To: The Linux Audio Developers' Mailing List
<linux-audio-dev(a)music.columbia.edu>
Message-ID: <20060614132522.GA3483(a)unununium.org>
Content-Type: text/plain; charset=us-ascii
On Wed, Jun 14, 2006 at 07:47:36AM +0200, Alex Polite wrote:
The realtime extension for snd (scheme-like language) is another:
http://www.notam02.no/arkiv/doc/snd-rt/
Here is a cool alsa softsynth written in that system:
http://ccrma.stanford.edu/~kjetil/220c/ Hi there.
Is it possible to write LADSPA plugins in anything but C/C++? I prefer
perl, ruby or python.
alex
Anything but C/C++, yes. See FAUST [1], a compiled language designed
specificly for processing audio streams. Perl, Ruby, or Python, not
really.
[1] <http://faudiostream.sourceforge.net/> 
8:52 a.m.
New subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language?
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.
9:56 a.m.
New subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language?
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:
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!
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. 
3 p.m.
New subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language?
On Thu, Jun 15, 2006 at 08:53:11AM -0400, Paul Davis
wrote:
>faust, btw, has no concept of a timeline in the sense that chuck does.
No, that's right. As I pointed out elsewhere in this thread, Faust is a
language for programming ugens, not for managing sequences and
playlists. We're talking about different levels of an audio processing
system here.
Alfons Adriaensen wrote:
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.
This is what Faust actually does. At the language level, it provides the
illusion of working with infinite streams of audio samples (or,
mathematically speaking, real-valued functions of discrete time) so that
you don't have to worry about the state which has to be kept between
different blocks, the compiler will take care of that for you.
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.
Right. That's why the C code generated by Faust is essentially just the
bare-bones block processing callback which takes the actual block size
and the audio buffers as parameters. It's up to the different
"architectures" to decide how this routine is actually used in a manner
which is optimal with regard to a given "host system", be it Jack,
LADSAP, VST, SuperCollider or whatever.
Of course any domain-specific high-level language has its trade-offs of
convenience vs. implementation overhead vs. limits of the domain model.
This is hard to get right for low-level DSP programming because
efficiency is of utmost importance, but I think that Faust does this
pretty well. The only roadblock right now is that it is not suitable for
multirate processing yet, but Yann is working on that. Fons, I hope that
with your experience as a seasoned DSP programmer you will try Faust
some time; I think you might like it, and your feedback will surely be
valuable. :)
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
16 Jun
16 Jun
9:05 a.m.
New subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language?
On Thu, Jun 15, 2006 at 09:07:35PM +0200, Albert Graef wrote:
This is hard to get right for low-level DSP
programming because
efficiency is of utmost importance, but I think that Faust does this
pretty well. The only roadblock right now is that it is not suitable for
multirate processing yet, but Yann is working on that. Fons, I hope that
with your experience as a seasoned DSP programmer you will try Faust
some time; I think you might like it, and your feedback will surely be
valuable. :)
After the LAC presentation I already had a look of course, and yes
it looks like something I might like. But it will have to wait until
I manage to finish a few other things...
--
FA
Follie! Follie! Delirio vano e' questo!
1:05 p.m.
New subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language?
Alfons Adriaensen wrote:
After the LAC presentation I already had a look of
course, and yes
it looks like something I might like. But it will have to wait until
I manage to finish a few other things...
Yes, I'm voting for making the day 0x24 hours!
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
6775
days inactive
6777
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
5 participants
participants (5)
-
Albert Graef -
Alfons Adriaensen -
David Cournapeau -
Kjetil S. Matheussen -
Paul Davis