> Another think I don't like is that MIDI and GUI code has to
> be in the orchestra files.
>

You can write a GUI in Python, and run Csound from the GUI. Whenever I need 
a Python GUI for Csound, I use BoaConstructor to build the GUI; it uses 
wxPython and can make most any kind of GUI. Such GUIs are responsive and can 
easily stop and restart Csound.

>> The current regime requires csound to support its own internal
>> programming language.  It seems like it would be much better to
>> offload that effort by using an existing language (that is already
>> being maintained by others elsewhere).  I'd choose Python, because I
>> like it and because it is designed and suitable for novice
>> programmers, but there are several other languages that would work.
>> With the right interfaces, perhaps many languages could be used
>> simultaneously, and I would prefer this more catholic approach.
>
> I'm a Python fan but I don't think it's really applicable
> here.  What would a Python orchestra look like?  Would you
> have to run a Python interpreter at k-rate?  I like the
> general idea of signal flow.  I think it's a valid situation
> to use a domain specific language.  I'm not at all clear
> what that language would look like so if you have any ideas
> I'd like to see them.

A Python orchestra would be Python code to "compile" the existing C opcodes; 
a replacement for the orc language. The orc language in Csound is not 
interpreted; it is "compiled" into a DSP graph (a linked list of instrument 
instances, each of which is a linked list of opcode instances). All software 
synthesizers pretty much work this way.

Regards,
Mike



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net