On Wed, Oct 03, 2001 at 01:53:53PM -0700, John Lazzaro wrote: > It took around 3 weeks of design and coding to set sfront up to handle > audio drivers that used callbacks -- so for some sorts of applications, > at least, its a pretty straightforward retrofit. The sfront changes were > done in preparation for Portaudio (now in sfront 0.75) and CoreAudio > primarily, but hopefully JACK support will happen too, especially if > someone is interested enough to write an sfront audio driver and > contribute it.
Cool! Do you think it might be possible to write a LADSPA driver so that it would be possible to write LADSPA plugins in SAOL? I looked into this a while ago but I didn't get very far - I'm really not a C programmer so I get stuck on pretty simple things. The main thing I couldn't figure out was how to deal with control ports. If I understand LADSPA, the control ports of a LADSPA plugin only get one value per block of audio data, and the host - not the plugin - determines the blocksize. To borrow Csound terminology which (I think) SAOL shares, the blocksize corresponds to ksmps. But I believe that in SAOL, the SAOL orchestra wants to specify its own ksmps. So that would be an obstacle to compiling a LADSPA plugin from SAOL. Is this understanding correct? If so, is there any way to modify SAOL so that a compiled SAOL program can be told its K-rate at runtime? There's also the matter of naming the ports ... LADSPA ports generally have reasonably intelligible names; how could sfront be told what the names are and which port they go with? Any other obstacles? I'd be writing plugins today if I could do them in a higher-level language like SAOL... hell, we could mine the Csound CD for cool processing instruments and churn out plugins by the dozen! -- ................ paul winkler ................ custom calendars: http://www.calendargalaxy.com A member of ARMS: http://www.reacharms.com home page: http://www.slinkp.com
