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

lazzaro lazzaro at eecs.berkeley.edu
Thu Jun 15 18:26:25 UTC 2006


[feel free to redistribute this posting to other mailing lists]


On Jun 15, 2006, at 6:56 AM,  Paul Winkler wrote:

> And, is all the sfront / saol action happening somewhere
> that I'm not aware of? I was always disappointed that there
> didn't seem to be a lively community around saol.


No, the MIT mailing list went inactive a few years ago, and
to my knowledge a new one hasn't sprung up to replace it.
The only communication channel at the moment is the
mailing list to be notified of new sfront releases via freshmeat.net:

http://freshmeat.net/projects/sfront/

Which does have 10 subscribers, and I'm not one of them,
so there must be 11 sfront users left in the world (at least) :-).

I've actually spent the last few months going through my
queue of bug reports and feature requests, and updating
the code base.  But, these are the sorts of changes that
benefit from doing them in "batch mode" and then testing
thoroughly, so the plan is to hold off on a new release until
its time for me to switch back into teaching mode for the fall ...

Historically, a few things happened with sfront:

[1] The standardization of RTP MIDI via the IETF took priority,
and it took longer than I had thought (first running code happened
Christmas 2000, and the IESG approved the I-Ds a few months
ago:

http://www1.ietf.org/mail-archive/web/ietf-announce/current/ 
msg02110.html

We're now in the copy-editing queue (it takes a long time to
proof-read 250 pages of dense text ...), once this is done
we'll get our RFC numbers.

[2] It took a long time to really get a sense of where SAOL could
fit in the community ... I think pitching it as a Max/MSP or Pd
or SuperCollider or CSound competitor won't succeed ... instead,
I think it needs to be relaunched as "audio Postscript" -- an ISO/IEC
standard for normatively interchanging audio algorithms in a
domain-specific representation.  And, as a extra bonus, SAOL is
easier for human programmers to read/write than Postscript :-).

This is an old idea -- some of you may remember an editorial David
Wessel wrote about "audio Postscript" many years ago in Electronic
Musician magazine ...

Admittedly, SAOL is not perfect for this role -- being standardized
almost a decade ago, its inevitable that its dated in some
respects, and even during its birth some of its design decisions were
controversial.  But, I don't think that a core group of academic
and industrial folks would be willing to mount (another) 5 year  
effort to
standardize a better audio algorithm interchange language, unless  
they see
real evidence from the community that there's a need for such an effort.
And the best way to show that need is to try to insert SAOL
into markets for such an interchange format where SAOL's limitations
are not of great concern.


>> Sfront compiles a high-level music language (Structured Audio) to C,
>> and there's no reason in theory that audio drivers couldn't be  
>> written
>> for LADSPA.
>
> I remember asking you about this a couple years ago and you said
> it could be done, but you could only run one plugin instance
> at a time... .is that still the case? or am I misremembering?


You are remembering correctly ...

Basically, one of the "feature requests" in my queue is improving
the sfront audio driver API to remove this restriction, and to
reality-test it by writing an AudioUnits driver.  Until that happens,
yes, you'd be limited to single-instantiation for your LADSPA
driver ... realistically, I don't think "multiple instances" would  
make it
into the "late summer 2006" release, unless I get lucky and
finish earlier items in the queue ahead of schedule.  The priority
items are fixing real semantic bugs in the language implementation,
since sfront is serving as a de-facto secondary reference implementation
at this point, as saolc has trouble running a lot of correct SAOL  
code ...

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---





More information about the Linux-audio-dev mailing list