[CM] clm4

[Michael Gogins]

If you want to work with a C compiler, you could consider using the sfront compiler which compiles the MPEG-4 Structured Audio Orchestra Language code (a nicer syntax for a Csound like synthesizer) into C, which is then compiled to an executable program. I once had a VST instrument plugin that shelled out to run the SAOL compiler which I had modified to generate a shared library that my plugin then loaded and dispatched events to. This all worked fine and the 2 compile steps (SAOL code to C, C to shared library) did not take that long. Most "orchestras" are not that long and you end up with one long C compilation unit that is clean ANSI C that also does not take long to compile.

The sfront compiler is reasonably mature and seems to work well. 

Probably not that hard to make in Lisp a SAOL compiler, or a translator.

Who knows?

Regards,
Mike

-----Original Message-----
>From: Rick Taube <taube@uiuc.edu>
>Sent: Feb 7, 2008 1:58 PM
>To: CMdist CM <cmdist@ccrma.Stanford.EDU>
>Subject: [CM] clm4
>
>if another version of clm is in the works, one thing that would be  
>really nice ( from my perspective...) would be for definstrument to  
>generete a .c file in which all the instrument allocation is moved to  
>the C side. that way there is no lisp fasl, you just load libclm then  
>compile it to a .so file, load it, and then call the entry points  
>(say fm_violin ) and pass floats or int parameter values from lisp  
>(or whatever language you are working with.) .Im not sure how  
>envelopes could be passed, maybe as strings. or maybe you simply pass  
>ALL param values as a string that the C side parses, ie when  
>definstrument generated the C code it would examine the formals and  
>output C code that would parse a string containing possible input:
>
>void fm_violin( char * input) {
>   float beg = parse_required(input, 1, 0.0);
>   float dur = parse_required(intput, 2, .5);
>   ...
>   env ampenv = parse_keyword(input, "ampenv:", {0, 1, 100, 1});
>   ...
>   for (i=time_to_samp(beg, SRATE); i< time_to_samp(end, SRATE); i++)
>     outa(oscil( ...))
>}
>
>regardless, all the current lisp ffi code would go away and a  
>compiled ins it could be loaded into any in any environment that  
>allowed .so loading and string passing. people  could then define  
>their own scheme funcs to provided keyword args  etc:
>
>(load "libclm.so")
>(load "v.so")
>
>(defun fm-violin (beg dur pitch amp . args)
>   ( fm_violin (args-to-string beg dur pitch amp args) ))
>
>or to be a bit fancier,  a definstument would genreate two files,  
>a .c file and  a .lisp or .scm file that defines a lispy wrapper. but  
>neither the (definsturment ) nor the lisp wrapper it generates needs  
>to be compiled by lisp, just evalled.
>
>--rick
>
>
>
>
>_______________________________________________
>Cmdist mailing list
>Cmdist@ccrma.stanford.edu
>http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist