It have thought about the same thing.

Gabriel Maldonado, I think, has thought about it. Probably a number of Csound developers have had this thought.

It would be intensely desirable, but I do not think it is easy. I think it would require quite a bit more encapsulation of the Csound internals to separate them from the opcode structure. This in turn would probably require considerable simplification of the Csound "engine", which is much more complex than it needs to be since it does a great deal and has received contributions by all kinds of people over quite a long time.

It might be easier to develop a new language from scratch. I have attempted this a few times myself, but one of the huge advantages of Csound are the existing instrument definitions, the community, and so on. Since my focus is music not code, I've managed to stop myself from proceeding farther with these experiments, at least so far. 

My currrent prototype is C++ wrapped with Lua, but which could also be wrapped with Python or other SWIG-able languages. The instrument definition base class and many unit generators would be written in C++ and wrapped in Lua. One would then be able to write new instrument definitions in Lua, by subclassing the instrument definition base class with a new Lua class. CsoundVST already has something like this for compositional "Node" classes, which are C++ but can be subclassed in Python.

But someone who understands the orchestra compiler better than I would be in a better place to comment on this. John ffitch for sure, perhaps Istvan Varga.

I have been intrigued lately by Common Lisp Music and Nyquist. CLM in particular allows one to write instrument definitions in different languages. The CLM web pages have samples.

Regards,
Mike
-----Original Message-----
From: Victor Lazzarini 
Sent: Oct 21, 2005 2:00 PM
To: csound-devel@lists.sourceforge.net
Subject: [Cs-dev] extra API functionality


I wondered in the past whether it would be possible to
have API functions that could create an instrument,
load in opcodes, make the synthesis graph, etc.
In other words, bypass the csound language altogether.

Would this be possible? If so, desirable? Wouldn't
it be interesting to have the new parser using Csound
API functions to build the instruments in memory.

It might be possible then that other languages, rather than
the original csound might be used to build orchestras.
And possibly create instruments on-the-fly.

This was on my list of things to ask when the subject
of what we would like in the API came about.

Victor


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yeah, I have thought about this a lot as well!  I would like orch/sco syntax
checking, loading, performing, etc. to all be separate.  I would like to be
able to load one instrument at a time under host control, either from file
or from a string in memory.  I would like to be able to build a score in
memory and perform it without writing it out to a file.  I would like to be
able to perform multiple score snippets, discontinously, without reloading
the orch.  I would like to be able to set all arguments and parameters for
running any of these processes without building a set of command-line
arguments.  Etc, etc, etc.

These things would all be easier with new orch and score parsers and a new
overall architecture for Csound.  The current Csound API still essentially
treats Csound like a batch process -- pass in command-line arguments,
orchestra loading, prep, and score sorting all in one pass, then performance
all in one pass (essentially).

Michael is right, this would require a great deal more factorization of the
code.  I personally have filed these thoughts away in my mind under "for
Csound 6".

Anthony

Michael Gogins wrote on 10/21/05 2:47 PM:

> Probably a number of Csound developers have had this thought.
> 
> It would be intensely desirable, but I do not think it is easy. I think it
> would require quite a bit more encapsulation of the Csound internals to
> separate them from the opcode structure.



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net