[CM] clm4

[Bret Battey]

I can't pretend to understand the details of the idea, though at first
glance it seems to suggest some nice flexibility and elegance. I'm wondering
if it would still support the passing of data back OUT of the instrument
into the LISP (or whatever) calling environment -- i.e. the run* loop --
since this is crucial to my coding work over the last few years. (Alas I
still haven't had time to test whether run* works in SBCL Mac, since it
certainly no longer does in OpenMCL.)

I also wouldn't want a situation that would limit the length of envelopes
passed to instruments, since I am current passing humongous xy envelopes...
(which would, for example, vastly exceed what a Csound ftable is hardwired
to be able hold).

-=Bret 


On 7/2/08 6:58 pm, "Rick Taube" <taube@uiuc.edu> wrote:

> 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