I don't agree. I think that there are many advantages to using a general-purpose language. First, people would already know the syntax, or, if they don't, they could learn it from better docs. Second, the developers don't need to write a parser. The domain-specific part, which I agree is desirable, can come from a class library.

The technical reason for languages like Csound, Pure Data, and SuperCollider is that, in order to have both high runtime efficiency and dynamic compilation, the synthesizer is written as a directed acyclic graph of unit generators that the runtime compiler or parser can easily wire up. This kind of graph is not as flexible or powerful as the abstract syntax tree for a true high-level programming language; but that kind of AST can't be efficient without static compilation and optimization.

My suggestion for using Lua is based on the observation that it can be built with a just-in-time compiler that has been bookmarked as running as fast as compiled Java code which also runs with a JIT. The interface between C and Lua is simple and I wonder if it wouldn't be possible to wrap the Csound opcodes in a thin layer of Lua so that, after one's instrument definition has been JITed, it would run say only 50% slower than native Csound code. I think this would make writing Csound orchestras much easier.

Regards,
Mike


-----Original Message-----
>From: Erik de Castro Lopo 
>Sent: Jul 12, 2006 8:20 AM
>To: csound-devel@lists.sourceforge.net
>Subject: Re: [Cs-dev] Future of Csound
>
>Michael Gogins wrote:
>
>> 2. The attraction would be the ability to write Csound instrument 
>> definitions in Lua, a much more powerful language than the current Csound 
>> orchestra language.
>
>The problem is that lua is a general purpose language. Csound
>instruments are rather specialised and would probably benefit
>from a domain specific language.
>
>Erik
>-- 
>+-----------------------------------------------------------+
>  Erik de Castro Lopo
>+-----------------------------------------------------------+
>"It's pretty simple. [Large companies are] allowed to own either
>a content creation empire - a studio or label - or a playback
>device empire (Walkmans, or PCs). But ... can't have both."
>  -- Andrew Orlowski
>
>
>-------------------------------------------------------------------------
>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 understand that this would be an advantage given your method of
working, but for those of us who use Csound as a realtime synthesis
engine 50% slower would be a real problem. Unless I've misinterpreted
what you're saying (highly likely) and the lag would only be during
the initial compilation and thereafter Csound would run at the speed
of Csound?

Jonathan.

Michael Gogins  writes:

> I don't agree. I think that there are many advantages to using a general-purpose language. First, people would already know the syntax, or, if they don't, they could learn it from better docs. Second, the developers don't need to write a parser. The domain-specific part, which I agree is desirable, can come from a class library.
>
> The technical reason for languages like Csound, Pure Data, and SuperCollider is that, in order to have both high runtime efficiency and dynamic compilation, the synthesizer is written as a directed acyclic graph of unit generators that the runtime compiler or parser can easily wire up. This kind of graph is not as flexible or powerful as the abstract syntax tree for a true high-level programming language; but that kind of AST can't be efficient without static compilation and optimization.
>
> My suggestion for using Lua is based on the observation that it can be built with a just-in-time compiler that has been bookmarked as running as fast as compiled Java code which also runs with a JIT. The interface between C and Lua is simple and I wonder if it wouldn't be possible to wrap the Csound opcodes in a thin layer of Lua so that, after one's instrument definition has been JITed, it would run say only 50% slower than native Csound code. I think this would make writing Csound orchestras much easier.
>
> Regards,
> Mike
>
>
> -----Original Message-----
>>From: Erik de Castro Lopo 
>>Sent: Jul 12, 2006 8:20 AM
>>To: csound-devel@lists.sourceforge.net
>>Subject: Re: [Cs-dev] Future of Csound
>>
>>Michael Gogins wrote:
>>
>>> 2. The attraction would be the ability to write Csound instrument 
>>> definitions in Lua, a much more powerful language than the current Csound 
>>> orchestra language.
>>
>>The problem is that lua is a general purpose language. Csound
>>instruments are rather specialised and would probably benefit
>>from a domain specific language.
>>
>>Erik
>>-- 
>>+-----------------------------------------------------------+
>>  Erik de Castro Lopo
>>+-----------------------------------------------------------+
>>"It's pretty simple. [Large companies are] allowed to own either
>>a content creation empire - a studio or label - or a playback
>>device empire (Walkmans, or PCs). But ... can't have both."
>>  -- Andrew Orlowski
>>
>>
>>-------------------------------------------------------------------------
>>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