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

[feel free to redistribute this posting to other mailing lists] On Jun 15, 2006, at 6:56 AM, Paul Winkler wrote: 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. 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 ---