Hi Michael, Thanks for your post! I think it's a good time now for us all to take a bit of a step back now that many of the goals of Csound5 are accomplished to see where we're at and where we'd like to go. Like Erik I consider myself more of a user than a developer, though one who likes to do a bit of code too when useful. Lately I am thinking one thing that would be very big would be to introduce a new Score statement to do control signals. Something like: k start end "sigName" sigType values... So that one could write control rate signals for parameter automation in the score. sigType would be something like: 0 - linear 1 - exponential etc. with values being x,y pairs or whatever matches similar line generating opcodes are available in csound (line, linseg, expseg, transeg, etc.). Signame could be such that if it starts with gk, then it'd be a gk signal, if it started with z it could be a zak signal, otherwise it could be a buss signal. (There'd have to be a better way to choose, maybe an extra param to choose what variant of signal). I don't think there's a way to do this with just instruments and i-statements. Having this facility would make my life also a lot easier for implementing parameter automation in blue. =) I was thinking the other day that we don't have the facility to have a loop instantiate multiple copies of the same oscilator, and thought there isn't really an idea of scoped-variables in csound, which might be useful. I'm not sure how much I like the idea of Lua as a orch language as I find that coding csoundinstruments is not really that much of a bottle-neck in composing and that the existing language, while not completely clean, is fairly efficient to code in. I would rather have the parser redone so that we can extend the language to encompass for-loops, arrays, etc. (BTW: John, I remember there being talk of a possible student of yours doing a project this summer to implement the parser. Is this still happening? If not, after this weekend when we move into an apartment here in Warsaw, I should have a good bit amount of time to put work into getting the parser going.) Regarding the embedding of Csound mentioned in your article in a way that nyquist or CLM is done, I think that goes back to a discussion we had here where the graph of instruments and notelist, current time, etc. would all have to be able to stay in memory and programmatically alterable. That could be done, but I think would take a fair amount of work though might naturally happen in conjunction with parser work. steven On 7/11/06, Michael Gogins wrote: > A while ago I said I would post my suggestions for the future of Csound, and > for managing Csound development. Here they are. > > Best, > Mike > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net