I like the idea of programmatically building orchestras. This would make Csound work more like SuperCollider. The linked lists of INSTRTXTs and OPTXTs would be similar to compiled SynthDefs.

I like this because people could develop class libraries in, e.g., Lisp or Python or Java, for building instruments, and use that langauge as their sole language for composition and synthesis.

Regards,
Mike

-----Original Message-----
>From: Steven Yi 
>Sent: Aug 15, 2006 5:27 AM
>To: Victor.Lazzarini@nuim.ie, Developer discussions 
>Subject: Re: [Cs-dev] New Parser - Update
>
>Hi Victor and all,
>
>I was thinking of plugin languages too; it shouldn't be so tricky to
>add a plugin type that adds a parse and cleanup method and a name to
>select the language by.  It might possible to do it another way where
>one adds a property to the CsInstruments tag, something like:
>
>
>
>
>to select what language to use.
>
>John mentioned in his email that the ability to remove instruments is
>already there.  I think though that it seems that beyond just
>instrument replacement, what seems like it'd be useful is if one can
>instrospect and instrument and request swapping out of opcodes.  (This
>was something I believe Iain mentioned a while back).
>
>Thinking out loud, one way to do it would be to have API functions to
>return pointers to instruments.  Then, one could travers the linked
>lists of OPTXT's, find the ones you wanted to change or swap out.  One
>would have to have pretty good understanding of how all the pointers
>are setup, though some API functions could be made to take care of the
>housekeeping.  The INSTRTXT and OPTXT could be exposed via SWIG and
>extra accessor functions could be added to expose values from the
>structs.  There probably would have to have some kind of verification
>pass or clean up pass after the swap, insertion, or removal to make
>sure existing instances of instruments are updated. This could
>probably be done separately in the current csound setup as it all
>happens after parse time and at run time.
>
>To programmatically build up an orchestra though instead of parsing
>could also be interesting.  That would remove parsing altogether.  The
>functions I'm setting up for the new parser are fairly granular though
>tied to AST tokens, but something similar could be done as API
>functions.  Then one could use SWIG bound languages to create a CSOUND
>* and then create instruments programmatically. (I think you alluded
>to something like this before).  This could also be done currently
>outside of the new parser.
>
>steven
>
>
>On 8/15/06, Victor Lazzarini  wrote:
>> Steven,
>>
>> this is really good! The feature below will be excellent:
>> we could have plugin languages!
>>
>> Another thing we need to look at, which is slightly related
>> to doing the new parser is the possibility of loading and
>> unloading instruments after an initial compilation. This
>> would be highly desirable.
>>
>> Thanks for your work and good luck with it.
>>
>> Victor
>>
>> > Also to note, by having the AST, alternative frontend orc
>> > languages could be added with only the responsibility of
>> > building a valid AST, as the rest of the compiler chain
>> > would continue to work.
>> >
>> > Thanks!
>> > steven
>> >
>> > ----------------------------------------------------------
>> > --------------- 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
>> 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
>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

I agree that such dynamic building of instruments affords  
considerable flexibility in terms of algorithmic design and allows  
one to change the way one thinks about the relationship between  
rendering (orchestrating) and event generation.
If there is an overhead on this flexibility,  it would be good to  
have both options... machines are still not fast enough for some RT  
generation/processing :-(

ciao,

David

On 16/08/2006, at 12:06 AM, Michael Gogins wrote:

> I like the idea of programmatically building orchestras. This would  
> make Csound work more like SuperCollider. The linked lists of  
> INSTRTXTs and OPTXTs would be similar to compiled SynthDefs.
>
> I like this because people could develop class libraries in, e.g.,  
> Lisp or Python or Java, for building instruments, and use that  
> langauge as their sole language for composition and synthesis.
>
> Regards,
> Mike
>
> -----Original Message-----
>> From: Steven Yi 
>> Sent: Aug 15, 2006 5:27 AM
>> To: Victor.Lazzarini@nuim.ie, Developer discussions > devel@lists.sourceforge.net>
>> Subject: Re: [Cs-dev] New Parser - Update
>>
>> Hi Victor and all,
>>
>> I was thinking of plugin languages too; it shouldn't be so tricky to
>> add a plugin type that adds a parse and cleanup method and a name to
>> select the language by.  It might possible to do it another way where
>> one adds a property to the CsInstruments tag, something like:
>>
>> 
>> 
>>
>> to select what language to use.
>>
>> John mentioned in his email that the ability to remove instruments is
>> already there.  I think though that it seems that beyond just
>> instrument replacement, what seems like it'd be useful is if one can
>> instrospect and instrument and request swapping out of opcodes.   
>> (This
>> was something I believe Iain mentioned a while back).
>>
>> Thinking out loud, one way to do it would be to have API functions to
>> return pointers to instruments.  Then, one could travers the linked
>> lists of OPTXT's, find the ones you wanted to change or swap out.   
>> One
>> would have to have pretty good understanding of how all the pointers
>> are setup, though some API functions could be made to take care of  
>> the
>> housekeeping.  The INSTRTXT and OPTXT could be exposed via SWIG and
>> extra accessor functions could be added to expose values from the
>> structs.  There probably would have to have some kind of verification
>> pass or clean up pass after the swap, insertion, or removal to make
>> sure existing instances of instruments are updated. This could
>> probably be done separately in the current csound setup as it all
>> happens after parse time and at run time.
>>
>> To programmatically build up an orchestra though instead of parsing
>> could also be interesting.  That would remove parsing altogether.   
>> The
>> functions I'm setting up for the new parser are fairly granular  
>> though
>> tied to AST tokens, but something similar could be done as API
>> functions.  Then one could use SWIG bound languages to create a  
>> CSOUND
>> * and then create instruments programmatically. (I think you alluded
>> to something like this before).  This could also be done currently
>> outside of the new parser.
>>
>> steven
>>
>>
>> On 8/15/06, Victor Lazzarini  wrote:
>>> Steven,
>>>
>>> this is really good! The feature below will be excellent:
>>> we could have plugin languages!
>>>
>>> Another thing we need to look at, which is slightly related
>>> to doing the new parser is the possibility of loading and
>>> unloading instruments after an initial compilation. This
>>> would be highly desirable.
>>>
>>> Thanks for your work and good luck with it.
>>>
>>> Victor
>>>
>>>> Also to note, by having the AST, alternative frontend orc
>>>> languages could be added with only the responsibility of
>>>> building a valid AST, as the rest of the compiler chain
>>>> would continue to work.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> ----------------------------------------------------------
>>>> --------------- 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
>>> 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
>> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

_______________________________________
experimental polymedia:	www.avatar.com.au
Sonic Communications Research Group,
University of Canberra:	 www.canberra.edu.au





-------------------------------------------------------------------------
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