Does anyone working on Csound development have any experience with
LLVM? (http://llvm.org/).

The reason I ask is that I note LLVM is the back end for the new
numerical programming language Julia. Benchmarks given by the Julia
project show run times similar to LuaJIT (LLVM can be used to create a
regular compiler or a just in time compiler).

This would seem to offer hope for embedding the existing Csound
orchestra and score languages into a higher-level language, which
could be modeled on Julia or something else or even C++. It might be
possible to break down the wall between the Csound "engine" and the
Csound "language."

To clarify what I mean by this wall, of course there needs to be an
"engine" that runs the data flow graph to execute a piece. But if the
engine were written in the same language as the piece, there would not
be a wall. The language could be used to redefine the graph in ways
that currently are not possible.

Just what this might mean can be gathered from the project to rewrite
the Faust backend using LLVM (not clear what the status of this,
perhaps those of you who went to LAC2012 might know):

FAUST is a compiled language for real-time audio signal processing.
The name FAUST stands for Functional AUdio STream. Its programming
model combines two approaches: functional programming and block
diagram composition. You can think of FAUST as a structured block
diagram language with a textual syntax. The project aims at developing
a new backend for Faust that will directly produce LLVM IR instead of
the C++ class Faust currently produces. With a (yet to come) library
version of the Faust compiler, it will allow developers to embed Faust
+ LLVM JIT to dynamically define, compile on the fly and execute Faust
plug-ins. LLVM IR and tools also allows some nice bytecode
manipulations like "partial evaluation/specialization" that will also
be investigated.

Regards,
Mike

-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> Does anyone working on Csound development have any experience with
> LLVM? (http://llvm.org/).
>

Just a little.  I have a research student using LLVM for multicore
compilation ideas (not audio -- numerical mainly)

==John ff



------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I haven't done much Csound development, but I've used LLVM
successfully for some audio work.  Specifically I was generating
certain linear algebra functions (vector dot products, vector-matrix
multiplication, and Gaussian elimination) for specific classes of
sparse vectors, in which the exact class wasn't known until runtime.
The results were very good.

I've discussed the possibility of an LLVM backend for Csound with
Steven Yi to some extent.  I expect it could provide a significant
performance improvement over the existing engine.  There seem to be a
number of different approaches that can be taken towards an
implementation, which I'm probably not qualified to judge on the
merits.

I would also note that a number of people in the Haskell community
have been exploring higher-level languages with the aim of unifying
orchestra- and score-type statements, including some that use Csound
as a backend.  Personally I don't think this is likely to be
particularly fruitful, but that may be because I've already been
brainwashed into the orc/sco way of thinking.

John Lato

On Mon, Apr 23, 2012 at 6:31 PM, Michael Gogins
 wrote:
> Does anyone working on Csound development have any experience with
> LLVM? (http://llvm.org/).
>
> The reason I ask is that I note LLVM is the back end for the new
> numerical programming language Julia. Benchmarks given by the Julia
> project show run times similar to LuaJIT (LLVM can be used to create a
> regular compiler or a just in time compiler).
>
> This would seem to offer hope for embedding the existing Csound
> orchestra and score languages into a higher-level language, which
> could be modeled on Julia or something else or even C++. It might be
> possible to break down the wall between the Csound "engine" and the
> Csound "language."
>
> To clarify what I mean by this wall, of course there needs to be an
> "engine" that runs the data flow graph to execute a piece. But if the
> engine were written in the same language as the piece, there would not
> be a wall. The language could be used to redefine the graph in ways
> that currently are not possible.
>
> Just what this might mean can be gathered from the project to rewrite
> the Faust backend using LLVM (not clear what the status of this,
> perhaps those of you who went to LAC2012 might know):
>
> FAUST is a compiled language for real-time audio signal processing.
> The name FAUST stands for Functional AUdio STream. Its programming
> model combines two approaches: functional programming and block
> diagram composition. You can think of FAUST as a structured block
> diagram language with a textual syntax. The project aims at developing
> a new backend for Faust that will directly produce LLVM IR instead of
> the C++ class Faust currently produces. With a (yet to come) library
> version of the Faust compiler, it will allow developers to embed Faust
> + LLVM JIT to dynamically define, compile on the fly and execute Faust
> plug-ins. LLVM IR and tools also allows some nice bytecode
> manipulations like "partial evaluation/specialization" that will also
> be investigated.
>
> Regards,
> Mike
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Is llvm programming akin to assembler? I mean at the same level? How much would it affect portability? We have to be careful were not regressing into music 11 territory here.

Victor

On 23 Apr 2012, at 20:25, John Lato  wrote:

> I haven't done much Csound development, but I've used LLVM
> successfully for some audio work.  Specifically I was generating
> certain linear algebra functions (vector dot products, vector-matrix
> multiplication, and Gaussian elimination) for specific classes of
> sparse vectors, in which the exact class wasn't known until runtime.
> The results were very good.
> 
> I've discussed the possibility of an LLVM backend for Csound with
> Steven Yi to some extent.  I expect it could provide a significant
> performance improvement over the existing engine.  There seem to be a
> number of different approaches that can be taken towards an
> implementation, which I'm probably not qualified to judge on the
> merits.
> 
> I would also note that a number of people in the Haskell community
> have been exploring higher-level languages with the aim of unifying
> orchestra- and score-type statements, including some that use Csound
> as a backend.  Personally I don't think this is likely to be
> particularly fruitful, but that may be because I've already been
> brainwashed into the orc/sco way of thinking.
> 
> John Lato
> 
> On Mon, Apr 23, 2012 at 6:31 PM, Michael Gogins
>  wrote:
>> Does anyone working on Csound development have any experience with
>> LLVM? (http://llvm.org/).
>> 
>> The reason I ask is that I note LLVM is the back end for the new
>> numerical programming language Julia. Benchmarks given by the Julia
>> project show run times similar to LuaJIT (LLVM can be used to create a
>> regular compiler or a just in time compiler).
>> 
>> This would seem to offer hope for embedding the existing Csound
>> orchestra and score languages into a higher-level language, which
>> could be modeled on Julia or something else or even C++. It might be
>> possible to break down the wall between the Csound "engine" and the
>> Csound "language."
>> 
>> To clarify what I mean by this wall, of course there needs to be an
>> "engine" that runs the data flow graph to execute a piece. But if the
>> engine were written in the same language as the piece, there would not
>> be a wall. The language could be used to redefine the graph in ways
>> that currently are not possible.
>> 
>> Just what this might mean can be gathered from the project to rewrite
>> the Faust backend using LLVM (not clear what the status of this,
>> perhaps those of you who went to LAC2012 might know):
>> 
>> FAUST is a compiled language for real-time audio signal processing.
>> The name FAUST stands for Functional AUdio STream. Its programming
>> model combines two approaches: functional programming and block
>> diagram composition. You can think of FAUST as a structured block
>> diagram language with a textual syntax. The project aims at developing
>> a new backend for Faust that will directly produce LLVM IR instead of
>> the C++ class Faust currently produces. With a (yet to come) library
>> version of the Faust compiler, it will allow developers to embed Faust
>> + LLVM JIT to dynamically define, compile on the fly and execute Faust
>> plug-ins. LLVM IR and tools also allows some nice bytecode
>> manipulations like "partial evaluation/specialization" that will also
>> be investigated.
>> 
>> Regards,
>> Mike
>> 
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>> 
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have not worked with LLVM directly, but I've read and heard enough
to find it very interesting. At the same time, I wonder about the
feasibility of its use considering we are supporting iOS and Android
now.

Also, I think rewriting or reorganizing the graph should be possible
with Csound 6.  Sure, we won't be able to tap into the LLVM features
or community behind it, but I think it's fine and we should be able to
achieve what we want with Cs6.

As for Faust, there was a paper at the 2011 LAC by Albert Graf for
Faust, Pure (Albert's functional language), and LLVM:

http://lac.linuxaudio.org/2011/papers/29.pdf

And this page discusses LLVM and Faust:

http://www.grame.fr/~letz/faust_llvm.html

including directions on checking out the faust2 branch that has the
LLVM bytecode generation.

I did have a conversation with Albert this past LAC and remember him
mentioning the move from LLVM 2.x to 3.0 was not a trivial amount of
work.  It made think that it was a bit of a moving target.

If anyone else has more experience and could speak to LLVM and also
it's feasibility of being run on Android/iOS, that'd be great.

On Mon, Apr 23, 2012 at 8:25 PM, John Lato  wrote:
> I haven't done much Csound development, but I've used LLVM
> successfully for some audio work.  Specifically I was generating
> certain linear algebra functions (vector dot products, vector-matrix
> multiplication, and Gaussian elimination) for specific classes of
> sparse vectors, in which the exact class wasn't known until runtime.
> The results were very good.
>
> I've discussed the possibility of an LLVM backend for Csound with
> Steven Yi to some extent.  I expect it could provide a significant
> performance improvement over the existing engine.  There seem to be a
> number of different approaches that can be taken towards an
> implementation, which I'm probably not qualified to judge on the
> merits.
>
> I would also note that a number of people in the Haskell community
> have been exploring higher-level languages with the aim of unifying
> orchestra- and score-type statements, including some that use Csound
> as a backend.  Personally I don't think this is likely to be
> particularly fruitful, but that may be because I've already been
> brainwashed into the orc/sco way of thinking.
>
> John Lato
>
> On Mon, Apr 23, 2012 at 6:31 PM, Michael Gogins
>  wrote:
>> Does anyone working on Csound development have any experience with
>> LLVM? (http://llvm.org/).
>>
>> The reason I ask is that I note LLVM is the back end for the new
>> numerical programming language Julia. Benchmarks given by the Julia
>> project show run times similar to LuaJIT (LLVM can be used to create a
>> regular compiler or a just in time compiler).
>>
>> This would seem to offer hope for embedding the existing Csound
>> orchestra and score languages into a higher-level language, which
>> could be modeled on Julia or something else or even C++. It might be
>> possible to break down the wall between the Csound "engine" and the
>> Csound "language."
>>
>> To clarify what I mean by this wall, of course there needs to be an
>> "engine" that runs the data flow graph to execute a piece. But if the
>> engine were written in the same language as the piece, there would not
>> be a wall. The language could be used to redefine the graph in ways
>> that currently are not possible.
>>
>> Just what this might mean can be gathered from the project to rewrite
>> the Faust backend using LLVM (not clear what the status of this,
>> perhaps those of you who went to LAC2012 might know):
>>
>> FAUST is a compiled language for real-time audio signal processing.
>> The name FAUST stands for Functional AUdio STream. Its programming
>> model combines two approaches: functional programming and block
>> diagram composition. You can think of FAUST as a structured block
>> diagram language with a textual syntax. The project aims at developing
>> a new backend for Faust that will directly produce LLVM IR instead of
>> the C++ class Faust currently produces. With a (yet to come) library
>> version of the Faust compiler, it will allow developers to embed Faust
>> + LLVM JIT to dynamically define, compile on the fly and execute Faust
>> plug-ins. LLVM IR and tools also allows some nice bytecode
>> manipulations like "partial evaluation/specialization" that will also
>> be investigated.
>>
>> Regards,
>> Mike
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It is more akin to C, but in some ways more like the gcc project. It is meant to be a low level but portable way to implement compilers for other languages. http://llvm.org/ProjectsWithLLVM/

They try to make it as easy as possible to implement new backends for new hardware. They already have ARM and MIPS backends http://llvm.org/docs/ReleaseNotes.html#armintegratedassembler

On 04/23/2012 01:03 PM, Victor wrote:
> Is llvm programming akin to assembler? I mean at the same level? How much would it affect portability? We have to be careful were not regressing into music 11 territory here.
>
> Victor
>
> On 23 Apr 2012, at 20:25, John Lato  wrote:
>
>> I haven't done much Csound development, but I've used LLVM
>> successfully for some audio work.  Specifically I was generating
>> certain linear algebra functions (vector dot products, vector-matrix
>> multiplication, and Gaussian elimination) for specific classes of
>> sparse vectors, in which the exact class wasn't known until runtime.
>> The results were very good.
>>
>> I've discussed the possibility of an LLVM backend for Csound with
>> Steven Yi to some extent.  I expect it could provide a significant
>> performance improvement over the existing engine.  There seem to be a
>> number of different approaches that can be taken towards an
>> implementation, which I'm probably not qualified to judge on the
>> merits.
>>
>> I would also note that a number of people in the Haskell community
>> have been exploring higher-level languages with the aim of unifying
>> orchestra- and score-type statements, including some that use Csound
>> as a backend.  Personally I don't think this is likely to be
>> particularly fruitful, but that may be because I've already been
>> brainwashed into the orc/sco way of thinking.
>>
>> John Lato
>>
>> On Mon, Apr 23, 2012 at 6:31 PM, Michael Gogins
>>   wrote:
>>> Does anyone working on Csound development have any experience with
>>> LLVM? (http://llvm.org/).
>>>
>>> The reason I ask is that I note LLVM is the back end for the new
>>> numerical programming language Julia. Benchmarks given by the Julia
>>> project show run times similar to LuaJIT (LLVM can be used to create a
>>> regular compiler or a just in time compiler).
>>>
>>> This would seem to offer hope for embedding the existing Csound
>>> orchestra and score languages into a higher-level language, which
>>> could be modeled on Julia or something else or even C++. It might be
>>> possible to break down the wall between the Csound "engine" and the
>>> Csound "language."
>>>
>>> To clarify what I mean by this wall, of course there needs to be an
>>> "engine" that runs the data flow graph to execute a piece. But if the
>>> engine were written in the same language as the piece, there would not
>>> be a wall. The language could be used to redefine the graph in ways
>>> that currently are not possible.
>>>
>>> Just what this might mean can be gathered from the project to rewrite
>>> the Faust backend using LLVM (not clear what the status of this,
>>> perhaps those of you who went to LAC2012 might know):
>>>
>>> FAUST is a compiled language for real-time audio signal processing.
>>> The name FAUST stands for Functional AUdio STream. Its programming
>>> model combines two approaches: functional programming and block
>>> diagram composition. You can think of FAUST as a structured block
>>> diagram language with a textual syntax. The project aims at developing
>>> a new backend for Faust that will directly produce LLVM IR instead of
>>> the C++ class Faust currently produces. With a (yet to come) library
>>> version of the Faust compiler, it will allow developers to embed Faust
>>> + LLVM JIT to dynamically define, compile on the fly and execute Faust
>>> plug-ins. LLVM IR and tools also allows some nice bytecode
>>> manipulations like "partial evaluation/specialization" that will also
>>> be investigated.
>>>
>>> Regards,
>>> Mike
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> For Developers, A Lot Can Happen In A Second.
>>> Boundary is the first to Know...and Tell You.
>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I consider LLVM to be between C and assembler, perhaps closer to C.
Writing LLVM bitcode directly can be a bit awkward since it's in SSA
form, but it is possible.

I would strongly agree with Steven's impression of LLVM being a moving
target.  It also seems a bit unstable, although that could be due to
me generally inhabiting corner cases in the language.

To me, some of the most interesting stuff LLVM enables are runtime
linking optimizations.  Although it's certainly possible to use an
LLVM-based compiler to build code for iOS/Android, I can't speak to
the feasibility of running LLVM tools on either platforms, which would
be necessary to access those types of features.

John L.

On Mon, Apr 23, 2012 at 10:32 PM, Steven Yi  wrote:
> I have not worked with LLVM directly, but I've read and heard enough
> to find it very interesting. At the same time, I wonder about the
> feasibility of its use considering we are supporting iOS and Android
> now.
>
> Also, I think rewriting or reorganizing the graph should be possible
> with Csound 6.  Sure, we won't be able to tap into the LLVM features
> or community behind it, but I think it's fine and we should be able to
> achieve what we want with Cs6.
>
> As for Faust, there was a paper at the 2011 LAC by Albert Graf for
> Faust, Pure (Albert's functional language), and LLVM:
>
> http://lac.linuxaudio.org/2011/papers/29.pdf
>
> And this page discusses LLVM and Faust:
>
> http://www.grame.fr/~letz/faust_llvm.html
>
> including directions on checking out the faust2 branch that has the
> LLVM bytecode generation.
>
> I did have a conversation with Albert this past LAC and remember him
> mentioning the move from LLVM 2.x to 3.0 was not a trivial amount of
> work.  It made think that it was a bit of a moving target.
>
> If anyone else has more experience and could speak to LLVM and also
> it's feasibility of being run on Android/iOS, that'd be great.
>
> On Mon, Apr 23, 2012 at 8:25 PM, John Lato  wrote:
>> I haven't done much Csound development, but I've used LLVM
>> successfully for some audio work.  Specifically I was generating
>> certain linear algebra functions (vector dot products, vector-matrix
>> multiplication, and Gaussian elimination) for specific classes of
>> sparse vectors, in which the exact class wasn't known until runtime.
>> The results were very good.
>>
>> I've discussed the possibility of an LLVM backend for Csound with
>> Steven Yi to some extent.  I expect it could provide a significant
>> performance improvement over the existing engine.  There seem to be a
>> number of different approaches that can be taken towards an
>> implementation, which I'm probably not qualified to judge on the
>> merits.
>>
>> I would also note that a number of people in the Haskell community
>> have been exploring higher-level languages with the aim of unifying
>> orchestra- and score-type statements, including some that use Csound
>> as a backend.  Personally I don't think this is likely to be
>> particularly fruitful, but that may be because I've already been
>> brainwashed into the orc/sco way of thinking.
>>
>> John Lato
>>
>> On Mon, Apr 23, 2012 at 6:31 PM, Michael Gogins
>>  wrote:
>>> Does anyone working on Csound development have any experience with
>>> LLVM? (http://llvm.org/).
>>>
>>> The reason I ask is that I note LLVM is the back end for the new
>>> numerical programming language Julia. Benchmarks given by the Julia
>>> project show run times similar to LuaJIT (LLVM can be used to create a
>>> regular compiler or a just in time compiler).
>>>
>>> This would seem to offer hope for embedding the existing Csound
>>> orchestra and score languages into a higher-level language, which
>>> could be modeled on Julia or something else or even C++. It might be
>>> possible to break down the wall between the Csound "engine" and the
>>> Csound "language."
>>>
>>> To clarify what I mean by this wall, of course there needs to be an
>>> "engine" that runs the data flow graph to execute a piece. But if the
>>> engine were written in the same language as the piece, there would not
>>> be a wall. The language could be used to redefine the graph in ways
>>> that currently are not possible.
>>>
>>> Just what this might mean can be gathered from the project to rewrite
>>> the Faust backend using LLVM (not clear what the status of this,
>>> perhaps those of you who went to LAC2012 might know):
>>>
>>> FAUST is a compiled language for real-time audio signal processing.
>>> The name FAUST stands for Functional AUdio STream. Its programming
>>> model combines two approaches: functional programming and block
>>> diagram composition. You can think of FAUST as a structured block
>>> diagram language with a textual syntax. The project aims at developing
>>> a new backend for Faust that will directly produce LLVM IR instead of
>>> the C++ class Faust currently produces. With a (yet to come) library
>>> version of the Faust compiler, it will allow developers to embed Faust
>>> + LLVM JIT to dynamically define, compile on the fly and execute Faust
>>> plug-ins. LLVM IR and tools also allows some nice bytecode
>>> manipulations like "partial evaluation/specialization" that will also
>>> be investigated.
>>>
>>> Regards,
>>> Mike
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> For Developers, A Lot Can Happen In A Second.
>>> Boundary is the first to Know...and Tell You.
>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Not only does LLVM run on Android, Google uses LLVM for the core of the Android platform.

Apple ships LLVM with its IOS SDK, and in general seems to be moving from using GCC to LLVM, IIRC primarily for performance reasons.

It may or may not be a moving target, but it is reasonable to expect that Google or Apple would simply fork it if it changed too radically (and csound could just start using that fork).

On 04/23/2012 04:14 PM, John Lato wrote:
> I consider LLVM to be between C and assembler, perhaps closer to C.
> Writing LLVM bitcode directly can be a bit awkward since it's in SSA
> form, but it is possible.
>
> I would strongly agree with Steven's impression of LLVM being a moving
> target.  It also seems a bit unstable, although that could be due to
> me generally inhabiting corner cases in the language.
>
> To me, some of the most interesting stuff LLVM enables are runtime
> linking optimizations.  Although it's certainly possible to use an
> LLVM-based compiler to build code for iOS/Android, I can't speak to
> the feasibility of running LLVM tools on either platforms, which would
> be necessary to access those types of features.
>
> John L.
>
> On Mon, Apr 23, 2012 at 10:32 PM, Steven Yi  wrote:
>> I have not worked with LLVM directly, but I've read and heard enough
>> to find it very interesting. At the same time, I wonder about the
>> feasibility of its use considering we are supporting iOS and Android
>> now.
>>
>> Also, I think rewriting or reorganizing the graph should be possible
>> with Csound 6.  Sure, we won't be able to tap into the LLVM features
>> or community behind it, but I think it's fine and we should be able to
>> achieve what we want with Cs6.
>>
>> As for Faust, there was a paper at the 2011 LAC by Albert Graf for
>> Faust, Pure (Albert's functional language), and LLVM:
>>
>> http://lac.linuxaudio.org/2011/papers/29.pdf
>>
>> And this page discusses LLVM and Faust:
>>
>> http://www.grame.fr/~letz/faust_llvm.html
>>
>> including directions on checking out the faust2 branch that has the
>> LLVM bytecode generation.
>>
>> I did have a conversation with Albert this past LAC and remember him
>> mentioning the move from LLVM 2.x to 3.0 was not a trivial amount of
>> work.  It made think that it was a bit of a moving target.
>>
>> If anyone else has more experience and could speak to LLVM and also
>> it's feasibility of being run on Android/iOS, that'd be great.
>>
>> On Mon, Apr 23, 2012 at 8:25 PM, John Lato  wrote:
>>> I haven't done much Csound development, but I've used LLVM
>>> successfully for some audio work.  Specifically I was generating
>>> certain linear algebra functions (vector dot products, vector-matrix
>>> multiplication, and Gaussian elimination) for specific classes of
>>> sparse vectors, in which the exact class wasn't known until runtime.
>>> The results were very good.
>>>
>>> I've discussed the possibility of an LLVM backend for Csound with
>>> Steven Yi to some extent.  I expect it could provide a significant
>>> performance improvement over the existing engine.  There seem to be a
>>> number of different approaches that can be taken towards an
>>> implementation, which I'm probably not qualified to judge on the
>>> merits.
>>>
>>> I would also note that a number of people in the Haskell community
>>> have been exploring higher-level languages with the aim of unifying
>>> orchestra- and score-type statements, including some that use Csound
>>> as a backend.  Personally I don't think this is likely to be
>>> particularly fruitful, but that may be because I've already been
>>> brainwashed into the orc/sco way of thinking.
>>>
>>> John Lato
>>>
>>> On Mon, Apr 23, 2012 at 6:31 PM, Michael Gogins
>>>   wrote:
>>>> Does anyone working on Csound development have any experience with
>>>> LLVM? (http://llvm.org/).
>>>>
>>>> The reason I ask is that I note LLVM is the back end for the new
>>>> numerical programming language Julia. Benchmarks given by the Julia
>>>> project show run times similar to LuaJIT (LLVM can be used to create a
>>>> regular compiler or a just in time compiler).
>>>>
>>>> This would seem to offer hope for embedding the existing Csound
>>>> orchestra and score languages into a higher-level language, which
>>>> could be modeled on Julia or something else or even C++. It might be
>>>> possible to break down the wall between the Csound "engine" and the
>>>> Csound "language."
>>>>
>>>> To clarify what I mean by this wall, of course there needs to be an
>>>> "engine" that runs the data flow graph to execute a piece. But if the
>>>> engine were written in the same language as the piece, there would not
>>>> be a wall. The language could be used to redefine the graph in ways
>>>> that currently are not possible.
>>>>
>>>> Just what this might mean can be gathered from the project to rewrite
>>>> the Faust backend using LLVM (not clear what the status of this,
>>>> perhaps those of you who went to LAC2012 might know):
>>>>
>>>> FAUST is a compiled language for real-time audio signal processing.
>>>> The name FAUST stands for Functional AUdio STream. Its programming
>>>> model combines two approaches: functional programming and block
>>>> diagram composition. You can think of FAUST as a structured block
>>>> diagram language with a textual syntax. The project aims at developing
>>>> a new backend for Faust that will directly produce LLVM IR instead of
>>>> the C++ class Faust currently produces. With a (yet to come) library
>>>> version of the Faust compiler, it will allow developers to embed Faust
>>>> + LLVM JIT to dynamically define, compile on the fly and execute Faust
>>>> plug-ins. LLVM IR and tools also allows some nice bytecode
>>>> manipulations like "partial evaluation/specialization" that will also
>>>> be investigated.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> For Developers, A Lot Can Happen In A Second.
>>>> Boundary is the first to Know...and Tell You.
>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> For Developers, A Lot Can Happen In A Second.
>>> Boundary is the first to Know...and Tell You.
>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Oh, I misunderstood part of what you were saying. LLVM jit is nominally working for ARM targets, but yes it seems to still be in progress.

On 04/23/2012 04:31 PM, Justin Glenn Smith wrote:
> Not only does LLVM run on Android, Google uses LLVM for the core of the
> Android platform.
>
> Apple ships LLVM with its IOS SDK, and in general seems to be moving
> from using GCC to LLVM, IIRC primarily for performance reasons.
>
> It may or may not be a moving target, but it is reasonable to expect
> that Google or Apple would simply fork it if it changed too radically
> (and csound could just start using that fork).
>
> On 04/23/2012 04:14 PM, John Lato wrote:
>> I consider LLVM to be between C and assembler, perhaps closer to C.
>> Writing LLVM bitcode directly can be a bit awkward since it's in SSA
>> form, but it is possible.
>>
>> I would strongly agree with Steven's impression of LLVM being a moving
>> target. It also seems a bit unstable, although that could be due to
>> me generally inhabiting corner cases in the language.
>>
>> To me, some of the most interesting stuff LLVM enables are runtime
>> linking optimizations. Although it's certainly possible to use an
>> LLVM-based compiler to build code for iOS/Android, I can't speak to
>> the feasibility of running LLVM tools on either platforms, which would
>> be necessary to access those types of features.
>>
>> John L.
>>
>> On Mon, Apr 23, 2012 at 10:32 PM, Steven Yi wrote:
>>> I have not worked with LLVM directly, but I've read and heard enough
>>> to find it very interesting. At the same time, I wonder about the
>>> feasibility of its use considering we are supporting iOS and Android
>>> now.
>>>
>>> Also, I think rewriting or reorganizing the graph should be possible
>>> with Csound 6. Sure, we won't be able to tap into the LLVM features
>>> or community behind it, but I think it's fine and we should be able to
>>> achieve what we want with Cs6.
>>>
>>> As for Faust, there was a paper at the 2011 LAC by Albert Graf for
>>> Faust, Pure (Albert's functional language), and LLVM:
>>>
>>> http://lac.linuxaudio.org/2011/papers/29.pdf
>>>
>>> And this page discusses LLVM and Faust:
>>>
>>> http://www.grame.fr/~letz/faust_llvm.html
>>>
>>> including directions on checking out the faust2 branch that has the
>>> LLVM bytecode generation.
>>>
>>> I did have a conversation with Albert this past LAC and remember him
>>> mentioning the move from LLVM 2.x to 3.0 was not a trivial amount of
>>> work. It made think that it was a bit of a moving target.
>>>
>>> If anyone else has more experience and could speak to LLVM and also
>>> it's feasibility of being run on Android/iOS, that'd be great.
>>>
>>> On Mon, Apr 23, 2012 at 8:25 PM, John Lato wrote:
>>>> I haven't done much Csound development, but I've used LLVM
>>>> successfully for some audio work. Specifically I was generating
>>>> certain linear algebra functions (vector dot products, vector-matrix
>>>> multiplication, and Gaussian elimination) for specific classes of
>>>> sparse vectors, in which the exact class wasn't known until runtime.
>>>> The results were very good.
>>>>
>>>> I've discussed the possibility of an LLVM backend for Csound with
>>>> Steven Yi to some extent. I expect it could provide a significant
>>>> performance improvement over the existing engine. There seem to be a
>>>> number of different approaches that can be taken towards an
>>>> implementation, which I'm probably not qualified to judge on the
>>>> merits.
>>>>
>>>> I would also note that a number of people in the Haskell community
>>>> have been exploring higher-level languages with the aim of unifying
>>>> orchestra- and score-type statements, including some that use Csound
>>>> as a backend. Personally I don't think this is likely to be
>>>> particularly fruitful, but that may be because I've already been
>>>> brainwashed into the orc/sco way of thinking.
>>>>
>>>> John Lato
>>>>
>>>> On Mon, Apr 23, 2012 at 6:31 PM, Michael Gogins
>>>>  wrote:
>>>>> Does anyone working on Csound development have any experience with
>>>>> LLVM? (http://llvm.org/).
>>>>>
>>>>> The reason I ask is that I note LLVM is the back end for the new
>>>>> numerical programming language Julia. Benchmarks given by the Julia
>>>>> project show run times similar to LuaJIT (LLVM can be used to create a
>>>>> regular compiler or a just in time compiler).
>>>>>
>>>>> This would seem to offer hope for embedding the existing Csound
>>>>> orchestra and score languages into a higher-level language, which
>>>>> could be modeled on Julia or something else or even C++. It might be
>>>>> possible to break down the wall between the Csound "engine" and the
>>>>> Csound "language."
>>>>>
>>>>> To clarify what I mean by this wall, of course there needs to be an
>>>>> "engine" that runs the data flow graph to execute a piece. But if the
>>>>> engine were written in the same language as the piece, there would not
>>>>> be a wall. The language could be used to redefine the graph in ways
>>>>> that currently are not possible.
>>>>>
>>>>> Just what this might mean can be gathered from the project to rewrite
>>>>> the Faust backend using LLVM (not clear what the status of this,
>>>>> perhaps those of you who went to LAC2012 might know):
>>>>>
>>>>> FAUST is a compiled language for real-time audio signal processing.
>>>>> The name FAUST stands for Functional AUdio STream. Its programming
>>>>> model combines two approaches: functional programming and block
>>>>> diagram composition. You can think of FAUST as a structured block
>>>>> diagram language with a textual syntax. The project aims at developing
>>>>> a new backend for Faust that will directly produce LLVM IR instead of
>>>>> the C++ class Faust currently produces. With a (yet to come) library
>>>>> version of the Faust compiler, it will allow developers to embed Faust
>>>>> + LLVM JIT to dynamically define, compile on the fly and execute Faust
>>>>> plug-ins. LLVM IR and tools also allows some nice bytecode
>>>>> manipulations like "partial evaluation/specialization" that will also
>>>>> be investigated.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> For Developers, A Lot Can Happen In A Second.
>>>>> Boundary is the first to Know...and Tell You.
>>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> For Developers, A Lot Can Happen In A Second.
>>>> Boundary is the first to Know...and Tell You.
>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> For Developers, A Lot Can Happen In A Second.
>>> Boundary is the first to Know...and Tell You.
>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>>
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor wrote:

> Is llvm programming akin to assembler?

In some ways yes, but it's a typed assembly language [0], with a the system
that is stronger than C's. 

> I mean at the same level?

Pretty much.

> How much would it affect portability?

LLVM is a platform neutral assembly language that can easily be translated
into a real assembly language for a large number of CPUs.


Cheers,
Erik

[0] I added an LLVM backend to an experimental compiler called DDC. The compiler
    already had a via-C backend but the LLVM work uncovered a number of type
    errors in the conversion from the DDC core langauge to C/LLVM.
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Permit me to call attention to my original motive for mentioning LLVM:
to enable Csound to be a language in which both the data flow graph
(the "engine") and the pieces that are rendered by the graph are
implemented in the same language.

Currently, this is not the case in any software sound synthesis system
that I am aware of. The closest that we come to this are C++ libraries
such as STK or CLAM, which one may use to write pieces. But such
pieces must be statically compiled. Using the LLVM JIT facilities
would, obviously, enable dynamic compilation.

Unifying the compositional language with the runtime would be one
means of accomplishing many of the goals that we set ourselves for
Csound 6: notably the ability to write Csound instrument definitions
in a higher-level language, better debugging facilities, and perhaps
it might be possible to write some sort of FFI facility so Csound code
can just call directly into C shared libraries. But mainly, Csound
code would have access to the "engine" at all levels.

Regards,
Mike

On Mon, Apr 23, 2012 at 8:01 PM, Erik de Castro Lopo
 wrote:
> Victor wrote:
>
>> Is llvm programming akin to assembler?
>
> In some ways yes, but it's a typed assembly language [0], with a the system
> that is stronger than C's.
>
>> I mean at the same level?
>
> Pretty much.
>
>> How much would it affect portability?
>
> LLVM is a platform neutral assembly language that can easily be translated
> into a real assembly language for a large number of CPUs.
>
>
> Cheers,
> Erik
>
> [0] I added an LLVM backend to an experimental compiler called DDC. The compiler
>    already had a via-C backend but the LLVM work uncovered a number of type
>    errors in the conversion from the DDC core langauge to C/LLVM.
> --
> ----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:

> Just what this might mean can be gathered from the project to rewrite
> the Faust backend using LLVM (not clear what the status of this,
> perhaps those of you who went to LAC2012 might know):

This makes a lot of sense. Currently FAUST generates C++ code which
it then runs through a C++ compiler.

In my experience with the DDC compiler, the generated C code was rather
poor and nothing like what a human  would write. I suspect that the C
compiler had trouble optimising this highly non-idiomatic code.
Generating LLVM IR code instead was relatively easy, found some bugs in
the  compiler and produced faster executables.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The community?
On 24 Apr 2012, at 11:11, Tito Latini wrote:

> What is the difference between `extempore' and a hypothetical csound+llvm ?

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 24/04/2012 03:38, Michael Gogins wrote:
> Permit me to call attention to my original motive for mentioning LLVM:
> to enable Csound to be a language in which both the data flow graph
> (the "engine") and the pieces that are rendered by the graph are
> implemented in the same language.
>
> Currently, this is not the case in any software sound synthesis system
> that I am aware of.


I certainly don't wish to put a damper on any of these discussions, and 
I see all of the attractions of a 'common language" for engine and 
"pieces", but I still very much value the distinctiveness of the 
synthesis language and the scoring language(s), including in the 
latter's simplest form of note list, and in my own usage it very often 
arises that a common orchestra is used with many alternative scores, 
whether bundled in a csd or written separately. I hope that the 
principle of the orchestra and score is not consigned to the waste bin 
of history as being in any way obsolete or deprecated. Conceptually it 
still has all the merits and virtues it always had. Whatever changes are 
made, I hope the identity, character and idiom of Csound is retained, 
and that Csound6 does not become (yet) another attempt to change the 
language into something else.  There will never come a time when it is 
not possible to invent new languages!

I remain of the opinion that Csound is already very well placed to be, 
so to speak, a backend for higher-level languages (not least, SAOL) that 
can do whatever it is people want to do, and that, as ever, backwards 
compatibility remains a founding principle.

With the new parser in place, there is also plenty of scope to consider 
perhpas in the longer term  a formal reimplementation using whatever 
modern programming techniques and languages are presently in fashion. I 
am as it happens interested in the broader aspects of educational 
outreach, where a reduced and simplified language model ("Csound Lite") 
might be of great value in schools as a way to introduce music 
computing, supporting the new UK initiatives for CS in schools, for 
example; aiming at, say, Year 5s onwards.


Richard Dobson

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Please understand, everything I say takes for granted that Csound will
always be perfectly backwardly compatible for orc and sco files. This
is not negotiable and this feature is indeed one of the main reasons
that I use Csound to make my own music.

I believe that with Csound 6 and the current group of developers, now
is the time to seriously consider that move to a more advanced
infrastructure.

To restate what I am considering, it is to extend the syntax of the
orc language so that it includes higher-level language features and is
compiled at run time with LLVM. Then the "engine" would also be
written in the orc language. The use of LLVM appears to promise "C"
level performance with this approach. My own use of LuaJIT in similar
ways indicates that this may actually be possible. LuaJIT itself  does
not appear to be ready for prime time for this application, but LLVM
may be.

Regards,
Mike

On Tue, Apr 24, 2012 at 7:44 AM, Richard Dobson
 wrote:
> On 24/04/2012 03:38, Michael Gogins wrote:
>> Permit me to call attention to my original motive for mentioning LLVM:
>> to enable Csound to be a language in which both the data flow graph
>> (the "engine") and the pieces that are rendered by the graph are
>> implemented in the same language.
>>
>> Currently, this is not the case in any software sound synthesis system
>> that I am aware of.
>
>
> I certainly don't wish to put a damper on any of these discussions, and
> I see all of the attractions of a 'common language" for engine and
> "pieces", but I still very much value the distinctiveness of the
> synthesis language and the scoring language(s), including in the
> latter's simplest form of note list, and in my own usage it very often
> arises that a common orchestra is used with many alternative scores,
> whether bundled in a csd or written separately. I hope that the
> principle of the orchestra and score is not consigned to the waste bin
> of history as being in any way obsolete or deprecated. Conceptually it
> still has all the merits and virtues it always had. Whatever changes are
> made, I hope the identity, character and idiom of Csound is retained,
> and that Csound6 does not become (yet) another attempt to change the
> language into something else.  There will never come a time when it is
> not possible to invent new languages!
>
> I remain of the opinion that Csound is already very well placed to be,
> so to speak, a backend for higher-level languages (not least, SAOL) that
> can do whatever it is people want to do, and that, as ever, backwards
> compatibility remains a founding principle.
>
> With the new parser in place, there is also plenty of scope to consider
> perhpas in the longer term  a formal reimplementation using whatever
> modern programming techniques and languages are presently in fashion. I
> am as it happens interested in the broader aspects of educational
> outreach, where a reduced and simplified language model ("Csound Lite")
> might be of great value in schools as a way to introduce music
> computing, supporting the new UK initiatives for CS in schools, for
> example; aiming at, say, Year 5s onwards.
>
>
> Richard Dobson
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I like the idea of a csound-logo. That could be very interesting.

By the way, I think Csound is well placed to cater for the needs of the orc+sco 'paradigm' as well as
the no-sco one. There is still a lot to be said for the former though, even it has had a big battering in other quarters.

Victor

On 24 Apr 2012, at 12:44, Richard Dobson wrote:

> With the new parser in place, there is also plenty of scope to consider 
> perhpas in the longer term  a formal reimplementation using whatever 
> modern programming techniques and languages are presently in fashion. I 
> am as it happens interested in the broader aspects of educational 
> outreach, where a reduced and simplified language model ("Csound Lite") 
> might be of great value in schools as a way to introduce music 
> computing, supporting the new UK initiatives for CS in schools, for 
> example; aiming at, say, Year 5s onwards.

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Csound lego? Or a Csound logo? I think I'd prefer the lego...

On 24 April 2012 13:00, Victor Lazzarini  wrote:
> I like the idea of a csound-logo. That could be very interesting.
>
> By the way, I think Csound is well placed to cater for the needs of the orc+sco 'paradigm' as well as
> the no-sco one. There is still a lot to be said for the former though, even it has had a big battering in other quarters.
>
> Victor
>
> On 24 Apr 2012, at 12:44, Richard Dobson wrote:
>
>> With the new parser in place, there is also plenty of scope to consider
>> perhpas in the longer term  a formal reimplementation using whatever
>> modern programming techniques and languages are presently in fashion. I
>> am as it happens interested in the broader aspects of educational
>> outreach, where a reduced and simplified language model ("Csound Lite")
>> might be of great value in schools as a way to introduce music
>> computing, supporting the new UK initiatives for CS in schools, for
>> example; aiming at, say, Year 5s onwards.
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I will look at extempore more thoroughly. At first glance it has some
major things in common with how Csound in LLVM might turn out. I will
also look more at Impromptu although it seems to be based on OS X.

I must say I use functional programming but I abhor the syntax of Lisp
and Scheme. I much prefer a C type syntax. Of all the many languages
I've used, I actually find Python easiest to write, then C/C++, then
Lua.

Tito, what do you think Csound 6 should be like?

Regards,
Mike

On Tue, Apr 24, 2012 at 6:11 AM, Tito Latini  wrote:
>> Currently, this is not the case in any software sound synthesis system
>> that I am aware of. The closest that we come to this are C++ libraries
>> such as STK or CLAM, which one may use to write pieces. But such
>> pieces must be statically compiled. Using the LLVM JIT facilities
>> would, obviously, enable dynamic compilation.
>
> https://github.com/digego/extempore
> http://impromptu.moso.com.au/
>
> What is the difference between `extempore' and a hypothetical csound+llvm ?
>
> The opcodes? Rewritable, wrap-able, copy-and-paste-able, faust-able, etc
> The language? It is enough a parser.
>
> Who is Julia? Suggestion:
>
>  https://github.com/JuliaLang/julia/blob/27bc9b4deddf00c8caac4066509b4961f1db27c1/src/julia-parser.scm
>
> Lisp, again :)))
>
> tito
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Tue, Apr 24, 2012 at 08:57, Michael Gogins  wrote:
>
> To restate what I am considering, it is to extend the syntax of the
> orc language so that it includes higher-level language features and is
> compiled at run time with LLVM. Then the "engine" would also be
> written in the orc language. The use of LLVM appears to promise "C"
> level performance with this approach. My own use of LuaJIT in similar
> ways indicates that this may actually be possible. LuaJIT itself  does
> not appear to be ready for prime time for this application, but LLVM
> may be.

Am I right in understanding that you want to compile csound orc to
native code (by first adding a few extensions to make it possible)?
And as a second step, rewrite the engine in orc?

If this is correct, it looks extremely convoluted to me. All dynamic
manipulations that I can think of are possible by modifying the DSP
graph (ie, manipulate instruments while the engine is running) +
dynamic score creation (already possible) and deletion (not sure this
is). But then maybe I'm just not creative enough. What other
manipulations or features do you have in mind?


--

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.source

Not quite. We are talking about two different ways of doing the same
things. I believe that the LLVM approach might be LESS convoluted.
With both approaches, I expect most opcodes will remain as C or C++
code just as they are now, so no difference there.

With the current approach, a performance that involves manipulating
the "engine" or writing instrument definitions in a higher level
language will involve both Csound orc code and code in some other
high-level language such as C or Python.

With the LLVM approach, a performance that involves manipulating the
"engine" or writing instrument definitions in a higher level language
will simply use the Csound orc language and runtime compiler, which
will have been suitably extended with a type system, structs and
classes, lambdas, parallel constructs, etc. This is what LLVM seems to
make possible.

Regards,
Mike



On Tue, Apr 24, 2012 at 8:57 AM, Felipe Sateler  wrote:
> On Tue, Apr 24, 2012 at 08:57, Michael Gogins  wrote:
>>
>> To restate what I am considering, it is to extend the syntax of the
>> orc language so that it includes higher-level language features and is
>> compiled at run time with LLVM. Then the "engine" would also be
>> written in the orc language. The use of LLVM appears to promise "C"
>> level performance with this approach. My own use of LuaJIT in similar
>> ways indicates that this may actually be possible. LuaJIT itself  does
>> not appear to be ready for prime time for this application, but LLVM
>> may be.
>
> Am I right in understanding that you want to compile csound orc to
> native code (by first adding a few extensions to make it possible)?
> And as a second step, rewrite the engine in orc?
>
> If this is correct, it looks extremely convoluted to me. All dynamic
> manipulations that I can think of are possible by modifying the DSP
> graph (ie, manipulate instruments while the engine is running) +
> dynamic score creation (already possible) and deletion (not sure this
> is). But then maybe I'm just not creative enough. What other
> manipulations or features do you have in mind?
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

OK, I think I understand. Let me rephrase to see if I understood correctly:

1. It is desirable to be able to manipulate the engine within a performance.
2. It is desirable to be able to write both engine manipulations and
orchestra in the same language. For this, the orchestra language needs
to be extended with higher level constructs.
3. LLVM makes supporting higher level constructs easier.

==> Making use of LLVM to parse the orc code might make (1) and (2)
easier to achieve.

Is this correct?

On Tue, Apr 24, 2012 at 11:12, Michael Gogins  wrote:
> Not quite. We are talking about two different ways of doing the same
> things. I believe that the LLVM approach might be LESS convoluted.
> With both approaches, I expect most opcodes will remain as C or C++
> code just as they are now, so no difference there.
>
> With the current approach, a performance that involves manipulating
> the "engine" or writing instrument definitions in a higher level
> language will involve both Csound orc code and code in some other
> high-level language such as C or Python.
>
> With the LLVM approach, a performance that involves manipulating the
> "engine" or writing instrument definitions in a higher level language
> will simply use the Csound orc language and runtime compiler, which
> will have been suitably extended with a type system, structs and
> classes, lambdas, parallel constructs, etc. This is what LLVM seems to
> make possible.
>
> Regards,
> Mike
>
>
>
> On Tue, Apr 24, 2012 at 8:57 AM, Felipe Sateler  wrote:
>> On Tue, Apr 24, 2012 at 08:57, Michael Gogins  wrote:
>>>
>>> To restate what I am considering, it is to extend the syntax of the
>>> orc language so that it includes higher-level language features and is
>>> compiled at run time with LLVM. Then the "engine" would also be
>>> written in the orc language. The use of LLVM appears to promise "C"
>>> level performance with this approach. My own use of LuaJIT in similar
>>> ways indicates that this may actually be possible. LuaJIT itself  does
>>> not appear to be ready for prime time for this application, but LLVM
>>> may be.
>>
>> Am I right in understanding that you want to compile csound orc to
>> native code (by first adding a few extensions to make it possible)?
>> And as a second step, rewrite the engine in orc?
>>
>> If this is correct, it looks extremely convoluted to me. All dynamic
>> manipulations that I can think of are possible by modifying the DSP
>> graph (ie, manipulate instruments while the engine is running) +
>> dynamic score creation (already possible) and deletion (not sure this
>> is). But then maybe I'm just not creative enough. What other
>> manipulations or features do you have in mind?
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.

I'm in the process of writing Python prototype scripts and pseudocode
in attempt to gain a better understanding of what is needed to build a
better bridge between a lower level synth engine to a higher level
language for users. With the right bridge, I believe we could simply
the process of integrating Csound into higher level languages and even
creating a "Csound Lite/Logo" type language.

In particular I strongly believe that a sound server model, similar to
the one employed by SuperCollider, could drastically improve the
orc/sco paradigm. Imho, the scsynth/sclang and the orc/sco paradigms
are already conceptually very similar. The difference is that
SuperCollider has great communication between the two. For example, it
isn't one-way. This is just for the orc/sco, I'm not including the
Csound API in this.

If Csound6 supported JSON, and not just peripherally, it would be much
easier for users to do things at a higher level. I'm going with JSON
mostly because it's very lightweight and well supported, and maybe a
good match for the Csound6 API.

For example. Let's say every unit generator in Csound6 had a
corresponding JSON data structure that throughly described its
interface, including human readable descriptions of what the unit
generator does and descriptions of each input/output. A structure like
this could be used by a language like Python to create automatically
generate classes for everything.

Then inside inside Python, users could describe graphs / design
instruments without even considering what native Csound syntax looks
like. When it's time to compile an orchestra, or modify the current
synth runtime if Csound6 supports dynamic loading, unloading, Python
wraps it up in JSON, sends it to the server. This could potentially be
a near seamless process for users.

Being JSON, the same principle could be applied to other languages,
like javascript or ruby.

Best,
Jake



On Tue, Apr 24, 2012 at 4:44 AM, Richard Dobson
 wrote:
> I certainly don't wish to put a damper on any of these discussions, and
> I see all of the attractions of a 'common language" for engine and
> "pieces", but I still very much value the distinctiveness of the
> synthesis language and the scoring language(s), including in the
> latter's simplest form of note list, and in my own usage it very often
> arises that a common orchestra is used with many alternative scores,
> whether bundled in a csd or written separately. I hope that the
> principle of the orchestra and score is not consigned to the waste bin
> of history as being in any way obsolete or deprecated. Conceptually it
> still has all the merits and virtues it always had. Whatever changes are
> made, I hope the identity, character and idiom of Csound is retained,
> and that Csound6 does not become (yet) another attempt to change the
> language into something else.  There will never come a time when it is
> not possible to invent new languages!
>
> I remain of the opinion that Csound is already very well placed to be,
> so to speak, a backend for higher-level languages (not least, SAOL) that
> can do whatever it is people want to do, and that, as ever, backwards
> compatibility remains a founding principle.
>
> With the new parser in place, there is also plenty of scope to consider
> perhpas in the longer term  a formal reimplementation using whatever
> modern programming techniques and languages are presently in fashion. I
> am as it happens interested in the broader aspects of educational
> outreach, where a reduced and simplified language model ("Csound Lite")
> might be of great value in schools as a way to introduce music
> computing, supporting the new UK initiatives for CS in schools, for
> example; aiming at, say, Year 5s onwards.
>
>
> Richard Dobson
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
codehop.com | #code #art #music

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/

Yes.
Mike

On Tue, Apr 24, 2012 at 10:22 AM, Felipe Sateler  wrote:
> OK, I think I understand. Let me rephrase to see if I understood correctly:
>
> 1. It is desirable to be able to manipulate the engine within a performance.
> 2. It is desirable to be able to write both engine manipulations and
> orchestra in the same language. For this, the orchestra language needs
> to be extended with higher level constructs.
> 3. LLVM makes supporting higher level constructs easier.
>
> ==> Making use of LLVM to parse the orc code might make (1) and (2)
> easier to achieve.
>
> Is this correct?
>
> On Tue, Apr 24, 2012 at 11:12, Michael Gogins  wrote:
>> Not quite. We are talking about two different ways of doing the same
>> things. I believe that the LLVM approach might be LESS convoluted.
>> With both approaches, I expect most opcodes will remain as C or C++
>> code just as they are now, so no difference there.
>>
>> With the current approach, a performance that involves manipulating
>> the "engine" or writing instrument definitions in a higher level
>> language will involve both Csound orc code and code in some other
>> high-level language such as C or Python.
>>
>> With the LLVM approach, a performance that involves manipulating the
>> "engine" or writing instrument definitions in a higher level language
>> will simply use the Csound orc language and runtime compiler, which
>> will have been suitably extended with a type system, structs and
>> classes, lambdas, parallel constructs, etc. This is what LLVM seems to
>> make possible.
>>
>> Regards,
>> Mike
>>
>>
>>
>> On Tue, Apr 24, 2012 at 8:57 AM, Felipe Sateler  wrote:
>>> On Tue, Apr 24, 2012 at 08:57, Michael Gogins  wrote:
>>>>
>>>> To restate what I am considering, it is to extend the syntax of the
>>>> orc language so that it includes higher-level language features and is
>>>> compiled at run time with LLVM. Then the "engine" would also be
>>>> written in the orc language. The use of LLVM appears to promise "C"
>>>> level performance with this approach. My own use of LuaJIT in similar
>>>> ways indicates that this may actually be possible. LuaJIT itself  does
>>>> not appear to be ready for prime time for this application, but LLVM
>>>> may be.
>>>
>>> Am I right in understanding that you want to compile csound orc to
>>> native code (by first adding a few extensions to make it possible)?
>>> And as a second step, rewrite the engine in orc?
>>>
>>> If this is correct, it looks extremely convoluted to me. All dynamic
>>> manipulations that I can think of are possible by modifying the DSP
>>> graph (ie, manipulate instruments while the engine is running) +
>>> dynamic score creation (already possible) and deletion (not sure this
>>> is). But then maybe I'm just not creative enough. What other
>>> manipulations or features do you have in mind?
>>>
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

What I am suggesting is not moving away from the engine/language
paradigm. As long as the synthesizer must respond to an external score
or to real-time events, then there must be an engine implementing a
data flow graph that synthesizes audio in response to inputs.

But I am suggesting that the engine can and should, if possible, be
written in the same language as the orchestra. That would chop a layer
or two out of the cake. That would certainly simplify Csound and
probably even speed it up.

The original software sound synthesis systems used this model, e.g.
Mathews' original synthesizer, Music IVBF, and cmusic. LLVM would
enable this model to be resumed, only with self-contained, runtime
compilation.

Doing this would also do what you are suggesting, only in the Csound
language. It would not get in the way of doing this in other
languages, either.

Regards,
Mike


On Tue, Apr 24, 2012 at 10:27 AM, Jacob Joaquin  wrote:
> I'm in the process of writing Python prototype scripts and pseudocode
> in attempt to gain a better understanding of what is needed to build a
> better bridge between a lower level synth engine to a higher level
> language for users. With the right bridge, I believe we could simply
> the process of integrating Csound into higher level languages and even
> creating a "Csound Lite/Logo" type language.
>
> In particular I strongly believe that a sound server model, similar to
> the one employed by SuperCollider, could drastically improve the
> orc/sco paradigm. Imho, the scsynth/sclang and the orc/sco paradigms
> are already conceptually very similar. The difference is that
> SuperCollider has great communication between the two. For example, it
> isn't one-way. This is just for the orc/sco, I'm not including the
> Csound API in this.
>
> If Csound6 supported JSON, and not just peripherally, it would be much
> easier for users to do things at a higher level. I'm going with JSON
> mostly because it's very lightweight and well supported, and maybe a
> good match for the Csound6 API.
>
> For example. Let's say every unit generator in Csound6 had a
> corresponding JSON data structure that throughly described its
> interface, including human readable descriptions of what the unit
> generator does and descriptions of each input/output. A structure like
> this could be used by a language like Python to create automatically
> generate classes for everything.
>
> Then inside inside Python, users could describe graphs / design
> instruments without even considering what native Csound syntax looks
> like. When it's time to compile an orchestra, or modify the current
> synth runtime if Csound6 supports dynamic loading, unloading, Python
> wraps it up in JSON, sends it to the server. This could potentially be
> a near seamless process for users.
>
> Being JSON, the same principle could be applied to other languages,
> like javascript or ruby.
>
> Best,
> Jake
>
>
>
> On Tue, Apr 24, 2012 at 4:44 AM, Richard Dobson
>  wrote:
>> I certainly don't wish to put a damper on any of these discussions, and
>> I see all of the attractions of a 'common language" for engine and
>> "pieces", but I still very much value the distinctiveness of the
>> synthesis language and the scoring language(s), including in the
>> latter's simplest form of note list, and in my own usage it very often
>> arises that a common orchestra is used with many alternative scores,
>> whether bundled in a csd or written separately. I hope that the
>> principle of the orchestra and score is not consigned to the waste bin
>> of history as being in any way obsolete or deprecated. Conceptually it
>> still has all the merits and virtues it always had. Whatever changes are
>> made, I hope the identity, character and idiom of Csound is retained,
>> and that Csound6 does not become (yet) another attempt to change the
>> language into something else.  There will never come a time when it is
>> not possible to invent new languages!
>>
>> I remain of the opinion that Csound is already very well placed to be,
>> so to speak, a backend for higher-level languages (not least, SAOL) that
>> can do whatever it is people want to do, and that, as ever, backwards
>> compatibility remains a founding principle.
>>
>> With the new parser in place, there is also plenty of scope to consider
>> perhpas in the longer term  a formal reimplementation using whatever
>> modern programming techniques and languages are presently in fashion. I
>> am as it happens interested in the broader aspects of educational
>> outreach, where a reduced and simplified language model ("Csound Lite")
>> might be of great value in schools as a way to introduce music
>> computing, supporting the new UK initiatives for CS in schools, for
>> example; aiming at, say, Year 5s onwards.
>>
>>
>> Richard Dobson
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> codehop.com | #code #art #music
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Jake,

I disagree somewhat with what you are saying.  I think to force the
sound server model would greatly limits the design and usage of
csound. A server model can be added on top of a synchronous API, as
can an asynchronous model.  The design must instead be layered.  The
internal core of csound should be simple; all other things can then be
built on top of it.  Adding things like JSON or OSC as a primary
interface into the core is, in my opinion, limiting.

However, there is no reason a server model could not and should not be
made.  Rather, a server application can be done that it itself uses
the same core Csound API, and this application can be distributed with
Csound.  It could be made to communicate via OSC, JSON, etc., and can
be designed to use the API to internally communicate with an instance
of Csound, as well as handle communications with a client application.

In essence, by minimizing what Csound does in its core, we effectively
increase its usability. We start with the design that has the least
amount of latency and can introduce unknowns like network protocols on
top of it.  We can embed Csound directly or decide to use it in a
separate process.  (This is especially important for mobile
applications, where interprocess communication is prohibited or very
limited).

Thanks,
steven

On Tue, Apr 24, 2012 at 3:27 PM, Jacob Joaquin  wrote:
> I'm in the process of writing Python prototype scripts and pseudocode
> in attempt to gain a better understanding of what is needed to build a
> better bridge between a lower level synth engine to a higher level
> language for users. With the right bridge, I believe we could simply
> the process of integrating Csound into higher level languages and even
> creating a "Csound Lite/Logo" type language.
>
> In particular I strongly believe that a sound server model, similar to
> the one employed by SuperCollider, could drastically improve the
> orc/sco paradigm. Imho, the scsynth/sclang and the orc/sco paradigms
> are already conceptually very similar. The difference is that
> SuperCollider has great communication between the two. For example, it
> isn't one-way. This is just for the orc/sco, I'm not including the
> Csound API in this.
>
> If Csound6 supported JSON, and not just peripherally, it would be much
> easier for users to do things at a higher level. I'm going with JSON
> mostly because it's very lightweight and well supported, and maybe a
> good match for the Csound6 API.
>
> For example. Let's say every unit generator in Csound6 had a
> corresponding JSON data structure that throughly described its
> interface, including human readable descriptions of what the unit
> generator does and descriptions of each input/output. A structure like
> this could be used by a language like Python to create automatically
> generate classes for everything.
>
> Then inside inside Python, users could describe graphs / design
> instruments without even considering what native Csound syntax looks
> like. When it's time to compile an orchestra, or modify the current
> synth runtime if Csound6 supports dynamic loading, unloading, Python
> wraps it up in JSON, sends it to the server. This could potentially be
> a near seamless process for users.
>
> Being JSON, the same principle could be applied to other languages,
> like javascript or ruby.
>
> Best,
> Jake
>
>
>
> On Tue, Apr 24, 2012 at 4:44 AM, Richard Dobson
>  wrote:
>> I certainly don't wish to put a damper on any of these discussions, and
>> I see all of the attractions of a 'common language" for engine and
>> "pieces", but I still very much value the distinctiveness of the
>> synthesis language and the scoring language(s), including in the
>> latter's simplest form of note list, and in my own usage it very often
>> arises that a common orchestra is used with many alternative scores,
>> whether bundled in a csd or written separately. I hope that the
>> principle of the orchestra and score is not consigned to the waste bin
>> of history as being in any way obsolete or deprecated. Conceptually it
>> still has all the merits and virtues it always had. Whatever changes are
>> made, I hope the identity, character and idiom of Csound is retained,
>> and that Csound6 does not become (yet) another attempt to change the
>> language into something else.  There will never come a time when it is
>> not possible to invent new languages!
>>
>> I remain of the opinion that Csound is already very well placed to be,
>> so to speak, a backend for higher-level languages (not least, SAOL) that
>> can do whatever it is people want to do, and that, as ever, backwards
>> compatibility remains a founding principle.
>>
>> With the new parser in place, there is also plenty of scope to consider
>> perhpas in the longer term  a formal reimplementation using whatever
>> modern programming techniques and languages are presently in fashion. I
>> am as it happens interested in the broader aspects of educational
>> outreach, where a reduced and simplified language model ("Csound Lite")
>> might be of great value in schools as a way to introduce music
>> computing, supporting the new UK initiatives for CS in schools, for
>> example; aiming at, say, Year 5s onwards.
>>
>>
>> Richard Dobson
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> codehop.com | #code #art #music
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Which is why I'm excited about this. :)

On Tue, Apr 24, 2012 at 7:43 AM, Michael Gogins
 wrote:
> What I am suggesting is not moving away from the engine/language
> paradigm. As long as the synthesizer must respond to an external score
> or to real-time events, then there must be an engine implementing a
> data flow graph that synthesizes audio in response to inputs.
>
> But I am suggesting that the engine can and should, if possible, be
> written in the same language as the orchestra. That would chop a layer
> or two out of the cake. That would certainly simplify Csound and
> probably even speed it up.
>
> The original software sound synthesis systems used this model, e.g.
> Mathews' original synthesizer, Music IVBF, and cmusic. LLVM would
> enable this model to be resumed, only with self-contained, runtime
> compilation.
>
> Doing this would also do what you are suggesting, only in the Csound
> language. It would not get in the way of doing this in other
> languages, either.
>
> Regards,
> Mike
>
>
> On Tue, Apr 24, 2012 at 10:27 AM, Jacob Joaquin  wrote:
>> I'm in the process of writing Python prototype scripts and pseudocode
>> in attempt to gain a better understanding of what is needed to build a
>> better bridge between a lower level synth engine to a higher level
>> language for users. With the right bridge, I believe we could simply
>> the process of integrating Csound into higher level languages and even
>> creating a "Csound Lite/Logo" type language.
>>
>> In particular I strongly believe that a sound server model, similar to
>> the one employed by SuperCollider, could drastically improve the
>> orc/sco paradigm. Imho, the scsynth/sclang and the orc/sco paradigms
>> are already conceptually very similar. The difference is that
>> SuperCollider has great communication between the two. For example, it
>> isn't one-way. This is just for the orc/sco, I'm not including the
>> Csound API in this.
>>
>> If Csound6 supported JSON, and not just peripherally, it would be much
>> easier for users to do things at a higher level. I'm going with JSON
>> mostly because it's very lightweight and well supported, and maybe a
>> good match for the Csound6 API.
>>
>> For example. Let's say every unit generator in Csound6 had a
>> corresponding JSON data structure that throughly described its
>> interface, including human readable descriptions of what the unit
>> generator does and descriptions of each input/output. A structure like
>> this could be used by a language like Python to create automatically
>> generate classes for everything.
>>
>> Then inside inside Python, users could describe graphs / design
>> instruments without even considering what native Csound syntax looks
>> like. When it's time to compile an orchestra, or modify the current
>> synth runtime if Csound6 supports dynamic loading, unloading, Python
>> wraps it up in JSON, sends it to the server. This could potentially be
>> a near seamless process for users.
>>
>> Being JSON, the same principle could be applied to other languages,
>> like javascript or ruby.
>>
>> Best,
>> Jake
>>
>>
>>
>> On Tue, Apr 24, 2012 at 4:44 AM, Richard Dobson
>>  wrote:
>>> I certainly don't wish to put a damper on any of these discussions, and
>>> I see all of the attractions of a 'common language" for engine and
>>> "pieces", but I still very much value the distinctiveness of the
>>> synthesis language and the scoring language(s), including in the
>>> latter's simplest form of note list, and in my own usage it very often
>>> arises that a common orchestra is used with many alternative scores,
>>> whether bundled in a csd or written separately. I hope that the
>>> principle of the orchestra and score is not consigned to the waste bin
>>> of history as being in any way obsolete or deprecated. Conceptually it
>>> still has all the merits and virtues it always had. Whatever changes are
>>> made, I hope the identity, character and idiom of Csound is retained,
>>> and that Csound6 does not become (yet) another attempt to change the
>>> language into something else.  There will never come a time when it is
>>> not possible to invent new languages!
>>>
>>> I remain of the opinion that Csound is already very well placed to be,
>>> so to speak, a backend for higher-level languages (not least, SAOL) that
>>> can do whatever it is people want to do, and that, as ever, backwards
>>> compatibility remains a founding principle.
>>>
>>> With the new parser in place, there is also plenty of scope to consider
>>> perhpas in the longer term  a formal reimplementation using whatever
>>> modern programming techniques and languages are presently in fashion. I
>>> am as it happens interested in the broader aspects of educational
>>> outreach, where a reduced and simplified language model ("Csound Lite")
>>> might be of great value in schools as a way to introduce music
>>> computing, supporting the new UK initiatives for CS in schools, for
>>> example; aiming at, say, Year 5s onwards.
>>>
>>>
>>> Richard Dobson
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> codehop.com | #code #art #music
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
codehop.com | #code #art #music

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/list

I figured this would happen through the API, not necessarily built
into the core. Though I see in my original comments where I might have
muddled things up. So I think we're close to being on the same page
here. Myconcern is that all this amazing, very important, lower level
work will overshadow what happens in higher level work, when these two
areas would probably both benefit if they were designed in tandem. I'm
sure many of you are thinking in these terms, but the specifics aren't
making it to the list, yet.


On Tue, Apr 24, 2012 at 7:45 AM, Steven Yi  wrote:
> Hi Jake,
>
> I disagree somewhat with what you are saying.  I think to force the
> sound server model would greatly limits the design and usage of
> csound. A server model can be added on top of a synchronous API, as
> can an asynchronous model.  The design must instead be layered.  The
> internal core of csound should be simple; all other things can then be
> built on top of it.  Adding things like JSON or OSC as a primary
> interface into the core is, in my opinion, limiting.
>
> However, there is no reason a server model could not and should not be
> made.  Rather, a server application can be done that it itself uses
> the same core Csound API, and this application can be distributed with
> Csound.  It could be made to communicate via OSC, JSON, etc., and can
> be designed to use the API to internally communicate with an instance
> of Csound, as well as handle communications with a client application.
>
> In essence, by minimizing what Csound does in its core, we effectively
> increase its usability. We start with the design that has the least
> amount of latency and can introduce unknowns like network protocols on
> top of it.  We can embed Csound directly or decide to use it in a
> separate process.  (This is especially important for mobile
> applications, where interprocess communication is prohibited or very
> limited).
>
> Thanks,
> steven
>
> On Tue, Apr 24, 2012 at 3:27 PM, Jacob Joaquin  wrote:
>> I'm in the process of writing Python prototype scripts and pseudocode
>> in attempt to gain a better understanding of what is needed to build a
>> better bridge between a lower level synth engine to a higher level
>> language for users. With the right bridge, I believe we could simply
>> the process of integrating Csound into higher level languages and even
>> creating a "Csound Lite/Logo" type language.
>>
>> In particular I strongly believe that a sound server model, similar to
>> the one employed by SuperCollider, could drastically improve the
>> orc/sco paradigm. Imho, the scsynth/sclang and the orc/sco paradigms
>> are already conceptually very similar. The difference is that
>> SuperCollider has great communication between the two. For example, it
>> isn't one-way. This is just for the orc/sco, I'm not including the
>> Csound API in this.
>>
>> If Csound6 supported JSON, and not just peripherally, it would be much
>> easier for users to do things at a higher level. I'm going with JSON
>> mostly because it's very lightweight and well supported, and maybe a
>> good match for the Csound6 API.
>>
>> For example. Let's say every unit generator in Csound6 had a
>> corresponding JSON data structure that throughly described its
>> interface, including human readable descriptions of what the unit
>> generator does and descriptions of each input/output. A structure like
>> this could be used by a language like Python to create automatically
>> generate classes for everything.
>>
>> Then inside inside Python, users could describe graphs / design
>> instruments without even considering what native Csound syntax looks
>> like. When it's time to compile an orchestra, or modify the current
>> synth runtime if Csound6 supports dynamic loading, unloading, Python
>> wraps it up in JSON, sends it to the server. This could potentially be
>> a near seamless process for users.
>>
>> Being JSON, the same principle could be applied to other languages,
>> like javascript or ruby.
>>
>> Best,
>> Jake
>>
>>
>>
>> On Tue, Apr 24, 2012 at 4:44 AM, Richard Dobson
>>  wrote:
>>> I certainly don't wish to put a damper on any of these discussions, and
>>> I see all of the attractions of a 'common language" for engine and
>>> "pieces", but I still very much value the distinctiveness of the
>>> synthesis language and the scoring language(s), including in the
>>> latter's simplest form of note list, and in my own usage it very often
>>> arises that a common orchestra is used with many alternative scores,
>>> whether bundled in a csd or written separately. I hope that the
>>> principle of the orchestra and score is not consigned to the waste bin
>>> of history as being in any way obsolete or deprecated. Conceptually it
>>> still has all the merits and virtues it always had. Whatever changes are
>>> made, I hope the identity, character and idiom of Csound is retained,
>>> and that Csound6 does not become (yet) another attempt to change the
>>> language into something else.  There will never come a time when it is
>>> not possible to invent new languages!
>>>
>>> I remain of the opinion that Csound is already very well placed to be,
>>> so to speak, a backend for higher-level languages (not least, SAOL) that
>>> can do whatever it is people want to do, and that, as ever, backwards
>>> compatibility remains a founding principle.
>>>
>>> With the new parser in place, there is also plenty of scope to consider
>>> perhpas in the longer term  a formal reimplementation using whatever
>>> modern programming techniques and languages are presently in fashion. I
>>> am as it happens interested in the broader aspects of educational
>>> outreach, where a reduced and simplified language model ("Csound Lite")
>>> might be of great value in schools as a way to introduce music
>>> computing, supporting the new UK initiatives for CS in schools, for
>>> example; aiming at, say, Year 5s onwards.
>>>
>>>
>>> Richard Dobson
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> codehop.com | #code #art #music
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
codehop.com | #code #art #music

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.ne

I agree. I had a Csound server based on Python back in 2006. I think something like that can be built with Csound, but should not be imposed.

Victor
On 24 Apr 2012, at 15:45, Steven Yi wrote:

> Hi Jake,
> 
> I disagree somewhat with what you are saying.  I think to force the
> sound server model would greatly limits the design and usage of
> csound. A server model can be added on top of a synchronous API, as
> can an asynchronous model.  The design must instead be layered.  The
> internal core of csound should be simple; all other things can then be
> built on top of it.  Adding things like JSON or OSC as a primary
> interface into the core is, in my opinion, limiting.
> 
> However, there is no reason a server model could not and should not be
> made.  Rather, a server application can be done that it itself uses
> the same core Csound API, and this application can be distributed with
> Csound.  It could be made to communicate via OSC, JSON, etc., and can
> be designed to use the API to internally communicate with an instance
> of Csound, as well as handle communications with a client application.
> 
> In essence, by minimizing what Csound does in its core, we effectively
> increase its usability. We start with the design that has the least
> amount of latency and can introduce unknowns like network protocols on
> top of it.  We can embed Csound directly or decide to use it in a
> separate process.  (This is especially important for mobile
> applications, where interprocess communication is prohibited or very
> limited).
> 
> Thanks,
> steven
> 
> On Tue, Apr 24, 2012 at 3:27 PM, Jacob Joaquin  wrote:
>> I'm in the process of writing Python prototype scripts and pseudocode
>> in attempt to gain a better understanding of what is needed to build a
>> better bridge between a lower level synth engine to a higher level
>> language for users. With the right bridge, I believe we could simply
>> the process of integrating Csound into higher level languages and even
>> creating a "Csound Lite/Logo" type language.
>> 
>> In particular I strongly believe that a sound server model, similar to
>> the one employed by SuperCollider, could drastically improve the
>> orc/sco paradigm. Imho, the scsynth/sclang and the orc/sco paradigms
>> are already conceptually very similar. The difference is that
>> SuperCollider has great communication between the two. For example, it
>> isn't one-way. This is just for the orc/sco, I'm not including the
>> Csound API in this.
>> 
>> If Csound6 supported JSON, and not just peripherally, it would be much
>> easier for users to do things at a higher level. I'm going with JSON
>> mostly because it's very lightweight and well supported, and maybe a
>> good match for the Csound6 API.
>> 
>> For example. Let's say every unit generator in Csound6 had a
>> corresponding JSON data structure that throughly described its
>> interface, including human readable descriptions of what the unit
>> generator does and descriptions of each input/output. A structure like
>> this could be used by a language like Python to create automatically
>> generate classes for everything.
>> 
>> Then inside inside Python, users could describe graphs / design
>> instruments without even considering what native Csound syntax looks
>> like. When it's time to compile an orchestra, or modify the current
>> synth runtime if Csound6 supports dynamic loading, unloading, Python
>> wraps it up in JSON, sends it to the server. This could potentially be
>> a near seamless process for users.
>> 
>> Being JSON, the same principle could be applied to other languages,
>> like javascript or ruby.
>> 
>> Best,
>> Jake
>> 
>> 
>> 
>> On Tue, Apr 24, 2012 at 4:44 AM, Richard Dobson
>>  wrote:
>>> I certainly don't wish to put a damper on any of these discussions, and
>>> I see all of the attractions of a 'common language" for engine and
>>> "pieces", but I still very much value the distinctiveness of the
>>> synthesis language and the scoring language(s), including in the
>>> latter's simplest form of note list, and in my own usage it very often
>>> arises that a common orchestra is used with many alternative scores,
>>> whether bundled in a csd or written separately. I hope that the
>>> principle of the orchestra and score is not consigned to the waste bin
>>> of history as being in any way obsolete or deprecated. Conceptually it
>>> still has all the merits and virtues it always had. Whatever changes are
>>> made, I hope the identity, character and idiom of Csound is retained,
>>> and that Csound6 does not become (yet) another attempt to change the
>>> language into something else.  There will never come a time when it is
>>> not possible to invent new languages!
>>> 
>>> I remain of the opinion that Csound is already very well placed to be,
>>> so to speak, a backend for higher-level languages (not least, SAOL) that
>>> can do whatever it is people want to do, and that, as ever, backwards
>>> compatibility remains a founding principle.
>>> 
>>> With the new parser in place, there is also plenty of scope to consider
>>> perhpas in the longer term  a formal reimplementation using whatever
>>> modern programming techniques and languages are presently in fashion. I
>>> am as it happens interested in the broader aspects of educational
>>> outreach, where a reduced and simplified language model ("Csound Lite")
>>> might be of great value in schools as a way to introduce music
>>> computing, supporting the new UK initiatives for CS in schools, for
>>> example; aiming at, say, Year 5s onwards.
>>> 
>>> 
>>> Richard Dobson
>>> 
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> 
>> 
>> --
>> codehop.com | #code #art #music
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Conceptually, do developers consider the orchestra parser as it stands
now part of core Csound? Or as a layer that sits on top of the engine?

On Tue, Apr 24, 2012 at 8:03 AM, Victor Lazzarini
 wrote:
> I agree. I had a Csound server based on Python back in 2006. I think something like that can be built with Csound, but should not be imposed.
>
> Victor
> On 24 Apr 2012, at 15:45, Steven Yi wrote:
>
>> Hi Jake,
>>
>> I disagree somewhat with what you are saying.  I think to force the
>> sound server model would greatly limits the design and usage of
>> csound. A server model can be added on top of a synchronous API, as
>> can an asynchronous model.  The design must instead be layered.  The
>> internal core of csound should be simple; all other things can then be
>> built on top of it.  Adding things like JSON or OSC as a primary
>> interface into the core is, in my opinion, limiting.
>>
>> However, there is no reason a server model could not and should not be
>> made.  Rather, a server application can be done that it itself uses
>> the same core Csound API, and this application can be distributed with
>> Csound.  It could be made to communicate via OSC, JSON, etc., and can
>> be designed to use the API to internally communicate with an instance
>> of Csound, as well as handle communications with a client application.
>>
>> In essence, by minimizing what Csound does in its core, we effectively
>> increase its usability. We start with the design that has the least
>> amount of latency and can introduce unknowns like network protocols on
>> top of it.  We can embed Csound directly or decide to use it in a
>> separate process.  (This is especially important for mobile
>> applications, where interprocess communication is prohibited or very
>> limited).
>>
>> Thanks,
>> steven
>>
>> On Tue, Apr 24, 2012 at 3:27 PM, Jacob Joaquin  wrote:
>>> I'm in the process of writing Python prototype scripts and pseudocode
>>> in attempt to gain a better understanding of what is needed to build a
>>> better bridge between a lower level synth engine to a higher level
>>> language for users. With the right bridge, I believe we could simply
>>> the process of integrating Csound into higher level languages and even
>>> creating a "Csound Lite/Logo" type language.
>>>
>>> In particular I strongly believe that a sound server model, similar to
>>> the one employed by SuperCollider, could drastically improve the
>>> orc/sco paradigm. Imho, the scsynth/sclang and the orc/sco paradigms
>>> are already conceptually very similar. The difference is that
>>> SuperCollider has great communication between the two. For example, it
>>> isn't one-way. This is just for the orc/sco, I'm not including the
>>> Csound API in this.
>>>
>>> If Csound6 supported JSON, and not just peripherally, it would be much
>>> easier for users to do things at a higher level. I'm going with JSON
>>> mostly because it's very lightweight and well supported, and maybe a
>>> good match for the Csound6 API.
>>>
>>> For example. Let's say every unit generator in Csound6 had a
>>> corresponding JSON data structure that throughly described its
>>> interface, including human readable descriptions of what the unit
>>> generator does and descriptions of each input/output. A structure like
>>> this could be used by a language like Python to create automatically
>>> generate classes for everything.
>>>
>>> Then inside inside Python, users could describe graphs / design
>>> instruments without even considering what native Csound syntax looks
>>> like. When it's time to compile an orchestra, or modify the current
>>> synth runtime if Csound6 supports dynamic loading, unloading, Python
>>> wraps it up in JSON, sends it to the server. This could potentially be
>>> a near seamless process for users.
>>>
>>> Being JSON, the same principle could be applied to other languages,
>>> like javascript or ruby.
>>>
>>> Best,
>>> Jake
>>>
>>>
>>>
>>> On Tue, Apr 24, 2012 at 4:44 AM, Richard Dobson
>>>  wrote:
>>>> I certainly don't wish to put a damper on any of these discussions, and
>>>> I see all of the attractions of a 'common language" for engine and
>>>> "pieces", but I still very much value the distinctiveness of the
>>>> synthesis language and the scoring language(s), including in the
>>>> latter's simplest form of note list, and in my own usage it very often
>>>> arises that a common orchestra is used with many alternative scores,
>>>> whether bundled in a csd or written separately. I hope that the
>>>> principle of the orchestra and score is not consigned to the waste bin
>>>> of history as being in any way obsolete or deprecated. Conceptually it
>>>> still has all the merits and virtues it always had. Whatever changes are
>>>> made, I hope the identity, character and idiom of Csound is retained,
>>>> and that Csound6 does not become (yet) another attempt to change the
>>>> language into something else.  There will never come a time when it is
>>>> not possible to invent new languages!
>>>>
>>>> I remain of the opinion that Csound is already very well placed to be,
>>>> so to speak, a backend for higher-level languages (not least, SAOL) that
>>>> can do whatever it is people want to do, and that, as ever, backwards
>>>> compatibility remains a founding principle.
>>>>
>>>> With the new parser in place, there is also plenty of scope to consider
>>>> perhpas in the longer term  a formal reimplementation using whatever
>>>> modern programming techniques and languages are presently in fashion. I
>>>> am as it happens interested in the broader aspects of educational
>>>> outreach, where a reduced and simplified language model ("Csound Lite")
>>>> might be of great value in schools as a way to introduce music
>>>> computing, supporting the new UK initiatives for CS in schools, for
>>>> example; aiming at, say, Year 5s onwards.
>>>>
>>>>
>>>> Richard Dobson
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>> codehop.com | #code #art #music
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
codehop.com | #code #art #music

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-deve

For Csound 6, the plan is to separate them.

Victor
On 24 Apr 2012, at 16:11, Jacob Joaquin wrote:

> Conceptually, do developers consider the orchestra parser as it stands
> now part of core Csound? Or as a layer that sits on top of the engine?
> 
> On Tue, Apr 24, 2012 at 8:03 AM, Victor Lazzarini
>  wrote:
>> I agree. I had a Csound server based on Python back in 2006. I think something like that can be built with Csound, but should not be imposed.
>> 
>> Victor
>> On 24 Apr 2012, at 15:45, Steven Yi wrote:
>> 
>>> Hi Jake,
>>> 
>>> I disagree somewhat with what you are saying.  I think to force the
>>> sound server model would greatly limits the design and usage of
>>> csound. A server model can be added on top of a synchronous API, as
>>> can an asynchronous model.  The design must instead be layered.  The
>>> internal core of csound should be simple; all other things can then be
>>> built on top of it.  Adding things like JSON or OSC as a primary
>>> interface into the core is, in my opinion, limiting.
>>> 
>>> However, there is no reason a server model could not and should not be
>>> made.  Rather, a server application can be done that it itself uses
>>> the same core Csound API, and this application can be distributed with
>>> Csound.  It could be made to communicate via OSC, JSON, etc., and can
>>> be designed to use the API to internally communicate with an instance
>>> of Csound, as well as handle communications with a client application.
>>> 
>>> In essence, by minimizing what Csound does in its core, we effectively
>>> increase its usability. We start with the design that has the least
>>> amount of latency and can introduce unknowns like network protocols on
>>> top of it.  We can embed Csound directly or decide to use it in a
>>> separate process.  (This is especially important for mobile
>>> applications, where interprocess communication is prohibited or very
>>> limited).
>>> 
>>> Thanks,
>>> steven
>>> 
>>> On Tue, Apr 24, 2012 at 3:27 PM, Jacob Joaquin  wrote:
>>>> I'm in the process of writing Python prototype scripts and pseudocode
>>>> in attempt to gain a better understanding of what is needed to build a
>>>> better bridge between a lower level synth engine to a higher level
>>>> language for users. With the right bridge, I believe we could simply
>>>> the process of integrating Csound into higher level languages and even
>>>> creating a "Csound Lite/Logo" type language.
>>>> 
>>>> In particular I strongly believe that a sound server model, similar to
>>>> the one employed by SuperCollider, could drastically improve the
>>>> orc/sco paradigm. Imho, the scsynth/sclang and the orc/sco paradigms
>>>> are already conceptually very similar. The difference is that
>>>> SuperCollider has great communication between the two. For example, it
>>>> isn't one-way. This is just for the orc/sco, I'm not including the
>>>> Csound API in this.
>>>> 
>>>> If Csound6 supported JSON, and not just peripherally, it would be much
>>>> easier for users to do things at a higher level. I'm going with JSON
>>>> mostly because it's very lightweight and well supported, and maybe a
>>>> good match for the Csound6 API.
>>>> 
>>>> For example. Let's say every unit generator in Csound6 had a
>>>> corresponding JSON data structure that throughly described its
>>>> interface, including human readable descriptions of what the unit
>>>> generator does and descriptions of each input/output. A structure like
>>>> this could be used by a language like Python to create automatically
>>>> generate classes for everything.
>>>> 
>>>> Then inside inside Python, users could describe graphs / design
>>>> instruments without even considering what native Csound syntax looks
>>>> like. When it's time to compile an orchestra, or modify the current
>>>> synth runtime if Csound6 supports dynamic loading, unloading, Python
>>>> wraps it up in JSON, sends it to the server. This could potentially be
>>>> a near seamless process for users.
>>>> 
>>>> Being JSON, the same principle could be applied to other languages,
>>>> like javascript or ruby.
>>>> 
>>>> Best,
>>>> Jake
>>>> 
>>>> 
>>>> 
>>>> On Tue, Apr 24, 2012 at 4:44 AM, Richard Dobson
>>>>  wrote:
>>>>> I certainly don't wish to put a damper on any of these discussions, and
>>>>> I see all of the attractions of a 'common language" for engine and
>>>>> "pieces", but I still very much value the distinctiveness of the
>>>>> synthesis language and the scoring language(s), including in the
>>>>> latter's simplest form of note list, and in my own usage it very often
>>>>> arises that a common orchestra is used with many alternative scores,
>>>>> whether bundled in a csd or written separately. I hope that the
>>>>> principle of the orchestra and score is not consigned to the waste bin
>>>>> of history as being in any way obsolete or deprecated. Conceptually it
>>>>> still has all the merits and virtues it always had. Whatever changes are
>>>>> made, I hope the identity, character and idiom of Csound is retained,
>>>>> and that Csound6 does not become (yet) another attempt to change the
>>>>> language into something else.  There will never come a time when it is
>>>>> not possible to invent new languages!
>>>>> 
>>>>> I remain of the opinion that Csound is already very well placed to be,
>>>>> so to speak, a backend for higher-level languages (not least, SAOL) that
>>>>> can do whatever it is people want to do, and that, as ever, backwards
>>>>> compatibility remains a founding principle.
>>>>> 
>>>>> With the new parser in place, there is also plenty of scope to consider
>>>>> perhpas in the longer term  a formal reimplementation using whatever
>>>>> modern programming techniques and languages are presently in fashion. I
>>>>> am as it happens interested in the broader aspects of educational
>>>>> outreach, where a reduced and simplified language model ("Csound Lite")
>>>>> might be of great value in schools as a way to introduce music
>>>>> computing, supporting the new UK initiatives for CS in schools, for
>>>>> example; aiming at, say, Year 5s onwards.
>>>>> 
>>>>> 
>>>>> Richard Dobson
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> 
>>>> 
>>>> 
>>>> --
>>>> codehop.com | #code #art #music
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
> -- 
> codehop.com | #code #art #music
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Core csound is the ability to take a text file containing valid orc
and sco code, and optionally MIDI files or real-time events, and
produce a soundfile or realtime audio stream rendering that data. How
it happens is beside the point. APIs and such are on top of the core,
whatever it is.

At one time, there were several implementations of Csound, some quite
different internally (e.g. written in C++) from what we now have. But
since they could all do the above (more or less), they were all
implementations of core Csound.

So no, the parser is not core Csound.

The "engine" is not part of core Csound, either. Theoretically, it
would be possible to implement the Csound language by compiling it,
not into a list of instr templates instances and opcodes, but into C
code that would be compiled and run as a separate program. A successor
to Csound, SAOL, had an implementation, SAOLC, that did just that.
Most of the opcodes in SAOLC were actually repackaged Csound opcode
source code.

"Core csound" is a formal language, and a specification for what that
language must do.

Regards,
Mike

On Tue, Apr 24, 2012 at 12:06 PM, Victor Lazzarini
 wrote:
> For Csound 6, the plan is to separate them.
>
> Victor
> On 24 Apr 2012, at 16:11, Jacob Joaquin wrote:
>
>> Conceptually, do developers consider the orchestra parser as it stands
>> now part of core Csound? Or as a layer that sits on top of the engine?
>>
>> On Tue, Apr 24, 2012 at 8:03 AM, Victor Lazzarini
>>  wrote:
>>> I agree. I had a Csound server based on Python back in 2006. I think something like that can be built with Csound, but should not be imposed.
>>>
>>> Victor
>>> On 24 Apr 2012, at 15:45, Steven Yi wrote:
>>>
>>>> Hi Jake,
>>>>
>>>> I disagree somewhat with what you are saying.  I think to force the
>>>> sound server model would greatly limits the design and usage of
>>>> csound. A server model can be added on top of a synchronous API, as
>>>> can an asynchronous model.  The design must instead be layered.  The
>>>> internal core of csound should be simple; all other things can then be
>>>> built on top of it.  Adding things like JSON or OSC as a primary
>>>> interface into the core is, in my opinion, limiting.
>>>>
>>>> However, there is no reason a server model could not and should not be
>>>> made.  Rather, a server application can be done that it itself uses
>>>> the same core Csound API, and this application can be distributed with
>>>> Csound.  It could be made to communicate via OSC, JSON, etc., and can
>>>> be designed to use the API to internally communicate with an instance
>>>> of Csound, as well as handle communications with a client application.
>>>>
>>>> In essence, by minimizing what Csound does in its core, we effectively
>>>> increase its usability. We start with the design that has the least
>>>> amount of latency and can introduce unknowns like network protocols on
>>>> top of it.  We can embed Csound directly or decide to use it in a
>>>> separate process.  (This is especially important for mobile
>>>> applications, where interprocess communication is prohibited or very
>>>> limited).
>>>>
>>>> Thanks,
>>>> steven
>>>>
>>>> On Tue, Apr 24, 2012 at 3:27 PM, Jacob Joaquin  wrote:
>>>>> I'm in the process of writing Python prototype scripts and pseudocode
>>>>> in attempt to gain a better understanding of what is needed to build a
>>>>> better bridge between a lower level synth engine to a higher level
>>>>> language for users. With the right bridge, I believe we could simply
>>>>> the process of integrating Csound into higher level languages and even
>>>>> creating a "Csound Lite/Logo" type language.
>>>>>
>>>>> In particular I strongly believe that a sound server model, similar to
>>>>> the one employed by SuperCollider, could drastically improve the
>>>>> orc/sco paradigm. Imho, the scsynth/sclang and the orc/sco paradigms
>>>>> are already conceptually very similar. The difference is that
>>>>> SuperCollider has great communication between the two. For example, it
>>>>> isn't one-way. This is just for the orc/sco, I'm not including the
>>>>> Csound API in this.
>>>>>
>>>>> If Csound6 supported JSON, and not just peripherally, it would be much
>>>>> easier for users to do things at a higher level. I'm going with JSON
>>>>> mostly because it's very lightweight and well supported, and maybe a
>>>>> good match for the Csound6 API.
>>>>>
>>>>> For example. Let's say every unit generator in Csound6 had a
>>>>> corresponding JSON data structure that throughly described its
>>>>> interface, including human readable descriptions of what the unit
>>>>> generator does and descriptions of each input/output. A structure like
>>>>> this could be used by a language like Python to create automatically
>>>>> generate classes for everything.
>>>>>
>>>>> Then inside inside Python, users could describe graphs / design
>>>>> instruments without even considering what native Csound syntax looks
>>>>> like. When it's time to compile an orchestra, or modify the current
>>>>> synth runtime if Csound6 supports dynamic loading, unloading, Python
>>>>> wraps it up in JSON, sends it to the server. This could potentially be
>>>>> a near seamless process for users.
>>>>>
>>>>> Being JSON, the same principle could be applied to other languages,
>>>>> like javascript or ruby.
>>>>>
>>>>> Best,
>>>>> Jake
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 24, 2012 at 4:44 AM, Richard Dobson
>>>>>  wrote:
>>>>>> I certainly don't wish to put a damper on any of these discussions, and
>>>>>> I see all of the attractions of a 'common language" for engine and
>>>>>> "pieces", but I still very much value the distinctiveness of the
>>>>>> synthesis language and the scoring language(s), including in the
>>>>>> latter's simplest form of note list, and in my own usage it very often
>>>>>> arises that a common orchestra is used with many alternative scores,
>>>>>> whether bundled in a csd or written separately. I hope that the
>>>>>> principle of the orchestra and score is not consigned to the waste bin
>>>>>> of history as being in any way obsolete or deprecated. Conceptually it
>>>>>> still has all the merits and virtues it always had. Whatever changes are
>>>>>> made, I hope the identity, character and idiom of Csound is retained,
>>>>>> and that Csound6 does not become (yet) another attempt to change the
>>>>>> language into something else.  There will never come a time when it is
>>>>>> not possible to invent new languages!
>>>>>>
>>>>>> I remain of the opinion that Csound is already very well placed to be,
>>>>>> so to speak, a backend for higher-level languages (not least, SAOL) that
>>>>>> can do whatever it is people want to do, and that, as ever, backwards
>>>>>> compatibility remains a founding principle.
>>>>>>
>>>>>> With the new parser in place, there is also plenty of scope to consider
>>>>>> perhpas in the longer term  a formal reimplementation using whatever
>>>>>> modern programming techniques and languages are presently in fashion. I
>>>>>> am as it happens interested in the broader aspects of educational
>>>>>> outreach, where a reduced and simplified language model ("Csound Lite")
>>>>>> might be of great value in schools as a way to introduce music
>>>>>> computing, supporting the new UK initiatives for CS in schools, for
>>>>>> example; aiming at, say, Year 5s onwards.
>>>>>>
>>>>>>
>>>>>> Richard Dobson
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> codehop.com | #code #art #music
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> Dept. of Music
>>> NUI Maynooth Ireland
>>> tel.: +353 1 708 3545
>>> Victor dot Lazzarini AT nuim dot ie
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> codehop.com | #code #art #music
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm working my way through the semantics here. What happens between
the parsing of an orchestra/score and the rendering within the synth
engine? How will this be different in Csound6?


On Tue, Apr 24, 2012 at 9:49 AM, Michael Gogins
 wrote:
> Core csound is the ability to take a text file containing valid orc
> and sco code, and optionally MIDI files or real-time events, and
> produce a soundfile or realtime audio stream rendering that data. How
> it happens is beside the point. APIs and such are on top of the core,
> whatever it is.
>
> At one time, there were several implementations of Csound, some quite
> different internally (e.g. written in C++) from what we now have. But
> since they could all do the above (more or less), they were all
> implementations of core Csound.
>
> So no, the parser is not core Csound.
>
> The "engine" is not part of core Csound, either. Theoretically, it
> would be possible to implement the Csound language by compiling it,
> not into a list of instr templates instances and opcodes, but into C
> code that would be compiled and run as a separate program. A successor
> to Csound, SAOL, had an implementation, SAOLC, that did just that.
> Most of the opcodes in SAOLC were actually repackaged Csound opcode
> source code.
>
> "Core csound" is a formal language, and a specification for what that
> language must do.
>
> Regards,
> Mike
>
> On Tue, Apr 24, 2012 at 12:06 PM, Victor Lazzarini
>  wrote:
>> For Csound 6, the plan is to separate them.
>>
>> Victor
>> On 24 Apr 2012, at 16:11, Jacob Joaquin wrote:
>>
>>> Conceptually, do developers consider the orchestra parser as it stands
>>> now part of core Csound? Or as a layer that sits on top of the engine?
>>>
>>> On Tue, Apr 24, 2012 at 8:03 AM, Victor Lazzarini
>>>  wrote:
>>>> I agree. I had a Csound server based on Python back in 2006. I think something like that can be built with Csound, but should not be imposed.
>>>>
>>>> Victor
>>>> On 24 Apr 2012, at 15:45, Steven Yi wrote:
>>>>
>>>>> Hi Jake,
>>>>>
>>>>> I disagree somewhat with what you are saying.  I think to force the
>>>>> sound server model would greatly limits the design and usage of
>>>>> csound. A server model can be added on top of a synchronous API, as
>>>>> can an asynchronous model.  The design must instead be layered.  The
>>>>> internal core of csound should be simple; all other things can then be
>>>>> built on top of it.  Adding things like JSON or OSC as a primary
>>>>> interface into the core is, in my opinion, limiting.
>>>>>
>>>>> However, there is no reason a server model could not and should not be
>>>>> made.  Rather, a server application can be done that it itself uses
>>>>> the same core Csound API, and this application can be distributed with
>>>>> Csound.  It could be made to communicate via OSC, JSON, etc., and can
>>>>> be designed to use the API to internally communicate with an instance
>>>>> of Csound, as well as handle communications with a client application.
>>>>>
>>>>> In essence, by minimizing what Csound does in its core, we effectively
>>>>> increase its usability. We start with the design that has the least
>>>>> amount of latency and can introduce unknowns like network protocols on
>>>>> top of it.  We can embed Csound directly or decide to use it in a
>>>>> separate process.  (This is especially important for mobile
>>>>> applications, where interprocess communication is prohibited or very
>>>>> limited).
>>>>>
>>>>> Thanks,
>>>>> steven
>>>>>
>>>>> On Tue, Apr 24, 2012 at 3:27 PM, Jacob Joaquin  wrote:
>>>>>> I'm in the process of writing Python prototype scripts and pseudocode
>>>>>> in attempt to gain a better understanding of what is needed to build a
>>>>>> better bridge between a lower level synth engine to a higher level
>>>>>> language for users. With the right bridge, I believe we could simply
>>>>>> the process of integrating Csound into higher level languages and even
>>>>>> creating a "Csound Lite/Logo" type language.
>>>>>>
>>>>>> In particular I strongly believe that a sound server model, similar to
>>>>>> the one employed by SuperCollider, could drastically improve the
>>>>>> orc/sco paradigm. Imho, the scsynth/sclang and the orc/sco paradigms
>>>>>> are already conceptually very similar. The difference is that
>>>>>> SuperCollider has great communication between the two. For example, it
>>>>>> isn't one-way. This is just for the orc/sco, I'm not including the
>>>>>> Csound API in this.
>>>>>>
>>>>>> If Csound6 supported JSON, and not just peripherally, it would be much
>>>>>> easier for users to do things at a higher level. I'm going with JSON
>>>>>> mostly because it's very lightweight and well supported, and maybe a
>>>>>> good match for the Csound6 API.
>>>>>>
>>>>>> For example. Let's say every unit generator in Csound6 had a
>>>>>> corresponding JSON data structure that throughly described its
>>>>>> interface, including human readable descriptions of what the unit
>>>>>> generator does and descriptions of each input/output. A structure like
>>>>>> this could be used by a language like Python to create automatically
>>>>>> generate classes for everything.
>>>>>>
>>>>>> Then inside inside Python, users could describe graphs / design
>>>>>> instruments without even considering what native Csound syntax looks
>>>>>> like. When it's time to compile an orchestra, or modify the current
>>>>>> synth runtime if Csound6 supports dynamic loading, unloading, Python
>>>>>> wraps it up in JSON, sends it to the server. This could potentially be
>>>>>> a near seamless process for users.
>>>>>>
>>>>>> Being JSON, the same principle could be applied to other languages,
>>>>>> like javascript or ruby.
>>>>>>
>>>>>> Best,
>>>>>> Jake
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 24, 2012 at 4:44 AM, Richard Dobson
>>>>>>  wrote:
>>>>>>> I certainly don't wish to put a damper on any of these discussions, and
>>>>>>> I see all of the attractions of a 'common language" for engine and
>>>>>>> "pieces", but I still very much value the distinctiveness of the
>>>>>>> synthesis language and the scoring language(s), including in the
>>>>>>> latter's simplest form of note list, and in my own usage it very often
>>>>>>> arises that a common orchestra is used with many alternative scores,
>>>>>>> whether bundled in a csd or written separately. I hope that the
>>>>>>> principle of the orchestra and score is not consigned to the waste bin
>>>>>>> of history as being in any way obsolete or deprecated. Conceptually it
>>>>>>> still has all the merits and virtues it always had. Whatever changes are
>>>>>>> made, I hope the identity, character and idiom of Csound is retained,
>>>>>>> and that Csound6 does not become (yet) another attempt to change the
>>>>>>> language into something else.  There will never come a time when it is
>>>>>>> not possible to invent new languages!
>>>>>>>
>>>>>>> I remain of the opinion that Csound is already very well placed to be,
>>>>>>> so to speak, a backend for higher-level languages (not least, SAOL) that
>>>>>>> can do whatever it is people want to do, and that, as ever, backwards
>>>>>>> compatibility remains a founding principle.
>>>>>>>
>>>>>>> With the new parser in place, there is also plenty of scope to consider
>>>>>>> perhpas in the longer term  a formal reimplementation using whatever
>>>>>>> modern programming techniques and languages are presently in fashion. I
>>>>>>> am as it happens interested in the broader aspects of educational
>>>>>>> outreach, where a reduced and simplified language model ("Csound Lite")
>>>>>>> might be of great value in schools as a way to introduce music
>>>>>>> computing, supporting the new UK initiatives for CS in schools, for
>>>>>>> example; aiming at, say, Year 5s onwards.
>>>>>>>
>>>>>>>
>>>>>>> Richard Dobson
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Live Security Virtual Conference
>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> codehop.com | #code #art #music
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> Dept. of Music
>>>> NUI Maynooth Ireland
>>>> tel.: +353 1 708 3545
>>>> Victor dot Lazzarini AT nuim dot ie
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>> codehop.com | #code #art #music
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
codehop.com | #code #art #music

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourcef

OK, the semantics. Csound has 2 languages: the orchestra language
typically in a .orc file and the score language typically in a .sco
file.

A parser is a piece of code, the parser, that understands the syntax
of the language. It does this by separating the code into "tokens" or
keywords, variable names, constants, etc. and then assembling these
tokens into a "parse tree" or "abstract syntax tree" that represents
the grammatical relationship between the tokens. It's just like
diagramming a sentence in grade school.

A parser can merely "recognize" code (i.e. just parse it and say that
it is valid) or it can "compile" the code (i.e. attach some little
piece of code that actually does something, called a "semantic
action," to each node of the parse tree).

In Csound, the semantic actions invoked by the parser build the actual
"graph" which represents the instruments, ftables, and opcodes. This
can be considered a translation of the parse tree into another sort of
tree. In this graph or tree (a tree is a kind of graph), the Csound
engine automatically starts running; every kperiod it runs down all
the instr nodes, and for each instr it runs down all the opcode nodes,
and for each opcode it invokes the opadr function. At this point, the
opcodes are actually carrying out the semantic actions specified by
the syntax tree, in a repetitive sort of way.

Looping over the tree of instrs and opcodes is what the "engine" or
"runtime" does. There's not really much to it, most of the complexity
comes in managing the creation and activation of instrument instances
to handle score events that come from various sources. This usually
results in the insertion of a new instr instance into the list the
"engine" loops over. The actual performance loop is ridiculously
simple, just iterating down lists of pointers and calling a function
off each pointer.

The "rendering" is happens when the out opcodes in the "engine" tree
write audio to a file or device.

Csound used to have a handwritten parser; code originally written by
Barry Vercoe would read the orc file and build the runtime lists of
instrs and opcodes. The new parser uses the, well, parser, to turn orc
code into an abstract syntax tree and the semantic actions on the
nodes build the runtime lists in a hopefully more reliable and
flexible manner.

The important thing to understand is that in a normal computer
language, when the parser is done, nothing happens until the user runs
the compiled program, which could do anything you tell it to do. With
csound, there is this implicit assumption that the compiled program
will begin running automatically and that it will be a signal
processing graph attached to outputs.

Nobody ever seems to spell out all these little assumptions, but
they're vital to understanding what is really going on.

What will be different in Csound 6?

That is what we are trying to figure out -- what WILL be different in Csound 6?

We are sure about one thing -- we want the abstract syntax tree to be
exposed to programmers and composers via the API. This will make it
possible for example to have plugin instruments written in C or
whatever as well as the plugin opcodes we now have.

My thinking about LLVM is, well, maybe we can replace the existing
parser and the Csound language itself with a superset of the Csound
language that includes all the regular stuff in other high-level
languages as well as being backward compatible with all extant sco and
orc, and replace the Csound parser with the LLVM back end that will
take care of exposing the syntax tree for us. Then you won't need an
API to access the tree, or for that matter the engine, you will be
able to do it right from Csound code. You will still be able to do it
from other languages as well.

All the opcodes, drivers, etc. would remain as they are, but as
libraries for the LLVM back end.

The projects mentioned by Tito do something much like this, but
instead of using a parser for the Csound language they use parsers for
Lisp or Scheme. At least I think that is what they do. I don't know
what they do for the performance loop, that is something I will be
looking into.

Hope this helps,
Mike

Hope this helps,
Mike

On Tue, Apr 24, 2012 at 3:00 PM, Jacob Joaquin  wrote:
> I'm working my way through the semantics here. What happens between
> the parsing of an orchestra/score and the rendering within the synth
> engine? How will this be different in Csound6?
>
>
> On Tue, Apr 24, 2012 at 9:49 AM, Michael Gogins
>  wrote:
>> Core csound is the ability to take a text file containing valid orc
>> and sco code, and optionally MIDI files or real-time events, and
>> produce a soundfile or realtime audio stream rendering that data. How
>> it happens is beside the point. APIs and such are on top of the core,
>> whatever it is.
>>
>> At one time, there were several implementations of Csound, some quite
>> different internally (e.g. written in C++) from what we now have. But
>> since they could all do the above (more or less), they were all
>> implementations of core Csound.
>>
>> So no, the parser is not core Csound.
>>
>> The "engine" is not part of core Csound, either. Theoretically, it
>> would be possible to implement the Csound language by compiling it,
>> not into a list of instr templates instances and opcodes, but into C
>> code that would be compiled and run as a separate program. A successor
>> to Csound, SAOL, had an implementation, SAOLC, that did just that.
>> Most of the opcodes in SAOLC were actually repackaged Csound opcode
>> source code.
>>
>> "Core csound" is a formal language, and a specification for what that
>> language must do.
>>
>> Regards,
>> Mike
>>
>> On Tue, Apr 24, 2012 at 12:06 PM, Victor Lazzarini
>>  wrote:
>>> For Csound 6, the plan is to separate them.
>>>
>>> Victor
>>> On 24 Apr 2012, at 16:11, Jacob Joaquin wrote:
>>>
>>>> Conceptually, do developers consider the orchestra parser as it stands
>>>> now part of core Csound? Or as a layer that sits on top of the engine?
>>>>
>>>> On Tue, Apr 24, 2012 at 8:03 AM, Victor Lazzarini
>>>>  wrote:
>>>>> I agree. I had a Csound server based on Python back in 2006. I think something like that can be built with Csound, but should not be imposed.
>>>>>
>>>>> Victor
>>>>> On 24 Apr 2012, at 15:45, Steven Yi wrote:
>>>>>
>>>>>> Hi Jake,
>>>>>>
>>>>>> I disagree somewhat with what you are saying.  I think to force the
>>>>>> sound server model would greatly limits the design and usage of
>>>>>> csound. A server model can be added on top of a synchronous API, as
>>>>>> can an asynchronous model.  The design must instead be layered.  The
>>>>>> internal core of csound should be simple; all other things can then be
>>>>>> built on top of it.  Adding things like JSON or OSC as a primary
>>>>>> interface into the core is, in my opinion, limiting.
>>>>>>
>>>>>> However, there is no reason a server model could not and should not be
>>>>>> made.  Rather, a server application can be done that it itself uses
>>>>>> the same core Csound API, and this application can be distributed with
>>>>>> Csound.  It could be made to communicate via OSC, JSON, etc., and can
>>>>>> be designed to use the API to internally communicate with an instance
>>>>>> of Csound, as well as handle communications with a client application.
>>>>>>
>>>>>> In essence, by minimizing what Csound does in its core, we effectively
>>>>>> increase its usability. We start with the design that has the least
>>>>>> amount of latency and can introduce unknowns like network protocols on
>>>>>> top of it.  We can embed Csound directly or decide to use it in a
>>>>>> separate process.  (This is especially important for mobile
>>>>>> applications, where interprocess communication is prohibited or very
>>>>>> limited).
>>>>>>
>>>>>> Thanks,
>>>>>> steven
>>>>>>
>>>>>> On Tue, Apr 24, 2012 at 3:27 PM, Jacob Joaquin  wrote:
>>>>>>> I'm in the process of writing Python prototype scripts and pseudocode
>>>>>>> in attempt to gain a better understanding of what is needed to build a
>>>>>>> better bridge between a lower level synth engine to a higher level
>>>>>>> language for users. With the right bridge, I believe we could simply
>>>>>>> the process of integrating Csound into higher level languages and even
>>>>>>> creating a "Csound Lite/Logo" type language.
>>>>>>>
>>>>>>> In particular I strongly believe that a sound server model, similar to
>>>>>>> the one employed by SuperCollider, could drastically improve the
>>>>>>> orc/sco paradigm. Imho, the scsynth/sclang and the orc/sco paradigms
>>>>>>> are already conceptually very similar. The difference is that
>>>>>>> SuperCollider has great communication between the two. For example, it
>>>>>>> isn't one-way. This is just for the orc/sco, I'm not including the
>>>>>>> Csound API in this.
>>>>>>>
>>>>>>> If Csound6 supported JSON, and not just peripherally, it would be much
>>>>>>> easier for users to do things at a higher level. I'm going with JSON
>>>>>>> mostly because it's very lightweight and well supported, and maybe a
>>>>>>> good match for the Csound6 API.
>>>>>>>
>>>>>>> For example. Let's say every unit generator in Csound6 had a
>>>>>>> corresponding JSON data structure that throughly described its
>>>>>>> interface, including human readable descriptions of what the unit
>>>>>>> generator does and descriptions of each input/output. A structure like
>>>>>>> this could be used by a language like Python to create automatically
>>>>>>> generate classes for everything.
>>>>>>>
>>>>>>> Then inside inside Python, users could describe graphs / design
>>>>>>> instruments without even considering what native Csound syntax looks
>>>>>>> like. When it's time to compile an orchestra, or modify the current
>>>>>>> synth runtime if Csound6 supports dynamic loading, unloading, Python
>>>>>>> wraps it up in JSON, sends it to the server. This could potentially be
>>>>>>> a near seamless process for users.
>>>>>>>
>>>>>>> Being JSON, the same principle could be applied to other languages,
>>>>>>> like javascript or ruby.
>>>>>>>
>>>>>>> Best,
>>>>>>> Jake
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 24, 2012 at 4:44 AM, Richard Dobson
>>>>>>>  wrote:
>>>>>>>> I certainly don't wish to put a damper on any of these discussions, and
>>>>>>>> I see all of the attractions of a 'common language" for engine and
>>>>>>>> "pieces", but I still very much value the distinctiveness of the
>>>>>>>> synthesis language and the scoring language(s), including in the
>>>>>>>> latter's simplest form of note list, and in my own usage it very often
>>>>>>>> arises that a common orchestra is used with many alternative scores,
>>>>>>>> whether bundled in a csd or written separately. I hope that the
>>>>>>>> principle of the orchestra and score is not consigned to the waste bin
>>>>>>>> of history as being in any way obsolete or deprecated. Conceptually it
>>>>>>>> still has all the merits and virtues it always had. Whatever changes are
>>>>>>>> made, I hope the identity, character and idiom of Csound is retained,
>>>>>>>> and that Csound6 does not become (yet) another attempt to change the
>>>>>>>> language into something else.  There will never come a time when it is
>>>>>>>> not possible to invent new languages!
>>>>>>>>
>>>>>>>> I remain of the opinion that Csound is already very well placed to be,
>>>>>>>> so to speak, a backend for higher-level languages (not least, SAOL) that
>>>>>>>> can do whatever it is people want to do, and that, as ever, backwards
>>>>>>>> compatibility remains a founding principle.
>>>>>>>>
>>>>>>>> With the new parser in place, there is also plenty of scope to consider
>>>>>>>> perhpas in the longer term  a formal reimplementation using whatever
>>>>>>>> modern programming techniques and languages are presently in fashion. I
>>>>>>>> am as it happens interested in the broader aspects of educational
>>>>>>>> outreach, where a reduced and simplified language model ("Csound Lite")
>>>>>>>> might be of great value in schools as a way to introduce music
>>>>>>>> computing, supporting the new UK initiatives for CS in schools, for
>>>>>>>> example; aiming at, say, Year 5s onwards.
>>>>>>>>
>>>>>>>>
>>>>>>>> Richard Dobson
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Live Security Virtual Conference
>>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> codehop.com | #code #art #music
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Live Security Virtual Conference
>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> Dr Victor Lazzarini
>>>>> Senior Lecturer
>>>>> Dept. of Music
>>>>> NUI Maynooth Ireland
>>>>> tel.: +353 1 708 3545
>>>>> Victor dot Lazzarini AT nuim dot ie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>> --
>>>> codehop.com | #code #art #music
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> Dept. of Music
>>> NUI Maynooth Ireland
>>> tel.: +353 1 708 3545
>>> Victor dot Lazzarini AT nuim dot ie
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> codehop.com | #code #art #music
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thank you. This is most helpful. I'll have follow up questions.


On Tue, Apr 24, 2012 at 12:39 PM, Michael Gogins
 wrote:
> OK, the semantics. Csound has 2 languages: the orchestra language
> typically in a .orc file and the score language typically in a .sco
> file.
>
> A parser is a piece of code, the parser, that understands the syntax
> of the language. It does this by separating the code into "tokens" or
> keywords, variable names, constants, etc. and then assembling these
> tokens into a "parse tree" or "abstract syntax tree" that represents
> the grammatical relationship between the tokens. It's just like
> diagramming a sentence in grade school.
>
> A parser can merely "recognize" code (i.e. just parse it and say that
> it is valid) or it can "compile" the code (i.e. attach some little
> piece of code that actually does something, called a "semantic
> action," to each node of the parse tree).
>
> In Csound, the semantic actions invoked by the parser build the actual
> "graph" which represents the instruments, ftables, and opcodes. This
> can be considered a translation of the parse tree into another sort of
> tree. In this graph or tree (a tree is a kind of graph), the Csound
> engine automatically starts running; every kperiod it runs down all
> the instr nodes, and for each instr it runs down all the opcode nodes,
> and for each opcode it invokes the opadr function. At this point, the
> opcodes are actually carrying out the semantic actions specified by
> the syntax tree, in a repetitive sort of way.
>
> Looping over the tree of instrs and opcodes is what the "engine" or
> "runtime" does. There's not really much to it, most of the complexity
> comes in managing the creation and activation of instrument instances
> to handle score events that come from various sources. This usually
> results in the insertion of a new instr instance into the list the
> "engine" loops over. The actual performance loop is ridiculously
> simple, just iterating down lists of pointers and calling a function
> off each pointer.
>
> The "rendering" is happens when the out opcodes in the "engine" tree
> write audio to a file or device.
>
> Csound used to have a handwritten parser; code originally written by
> Barry Vercoe would read the orc file and build the runtime lists of
> instrs and opcodes. The new parser uses the, well, parser, to turn orc
> code into an abstract syntax tree and the semantic actions on the
> nodes build the runtime lists in a hopefully more reliable and
> flexible manner.
>
> The important thing to understand is that in a normal computer
> language, when the parser is done, nothing happens until the user runs
> the compiled program, which could do anything you tell it to do. With
> csound, there is this implicit assumption that the compiled program
> will begin running automatically and that it will be a signal
> processing graph attached to outputs.
>
> Nobody ever seems to spell out all these little assumptions, but
> they're vital to understanding what is really going on.
>
> What will be different in Csound 6?
>
> That is what we are trying to figure out -- what WILL be different in Csound 6?
>
> We are sure about one thing -- we want the abstract syntax tree to be
> exposed to programmers and composers via the API. This will make it
> possible for example to have plugin instruments written in C or
> whatever as well as the plugin opcodes we now have.
>
> My thinking about LLVM is, well, maybe we can replace the existing
> parser and the Csound language itself with a superset of the Csound
> language that includes all the regular stuff in other high-level
> languages as well as being backward compatible with all extant sco and
> orc, and replace the Csound parser with the LLVM back end that will
> take care of exposing the syntax tree for us. Then you won't need an
> API to access the tree, or for that matter the engine, you will be
> able to do it right from Csound code. You will still be able to do it
> from other languages as well.
>
> All the opcodes, drivers, etc. would remain as they are, but as
> libraries for the LLVM back end.
>
> The projects mentioned by Tito do something much like this, but
> instead of using a parser for the Csound language they use parsers for
> Lisp or Scheme. At least I think that is what they do. I don't know
> what they do for the performance loop, that is something I will be
> looking into.
>
> Hope this helps,
> Mike
>
> Hope this helps,
> Mike
>
> On Tue, Apr 24, 2012 at 3:00 PM, Jacob Joaquin  wrote:
>> I'm working my way through the semantics here. What happens between
>> the parsing of an orchestra/score and the rendering within the synth
>> engine? How will this be different in Csound6?
>>
>>
>> On Tue, Apr 24, 2012 at 9:49 AM, Michael Gogins
>>  wrote:
>>> Core csound is the ability to take a text file containing valid orc
>>> and sco code, and optionally MIDI files or real-time events, and
>>> produce a soundfile or realtime audio stream rendering that data. How
>>> it happens is beside the point. APIs and such are on top of the core,
>>> whatever it is.
>>>
>>> At one time, there were several implementations of Csound, some quite
>>> different internally (e.g. written in C++) from what we now have. But
>>> since they could all do the above (more or less), they were all
>>> implementations of core Csound.
>>>
>>> So no, the parser is not core Csound.
>>>
>>> The "engine" is not part of core Csound, either. Theoretically, it
>>> would be possible to implement the Csound language by compiling it,
>>> not into a list of instr templates instances and opcodes, but into C
>>> code that would be compiled and run as a separate program. A successor
>>> to Csound, SAOL, had an implementation, SAOLC, that did just that.
>>> Most of the opcodes in SAOLC were actually repackaged Csound opcode
>>> source code.
>>>
>>> "Core csound" is a formal language, and a specification for what that
>>> language must do.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Tue, Apr 24, 2012 at 12:06 PM, Victor Lazzarini
>>>  wrote:
>>>> For Csound 6, the plan is to separate them.
>>>>
>>>> Victor
>>>> On 24 Apr 2012, at 16:11, Jacob Joaquin wrote:
>>>>
>>>>> Conceptually, do developers consider the orchestra parser as it stands
>>>>> now part of core Csound? Or as a layer that sits on top of the engine?
>>>>>
>>>>> On Tue, Apr 24, 2012 at 8:03 AM, Victor Lazzarini
>>>>>  wrote:
>>>>>> I agree. I had a Csound server based on Python back in 2006. I think something like that can be built with Csound, but should not be imposed.
>>>>>>
>>>>>> Victor
>>>>>> On 24 Apr 2012, at 15:45, Steven Yi wrote:
>>>>>>
>>>>>>> Hi Jake,
>>>>>>>
>>>>>>> I disagree somewhat with what you are saying.  I think to force the
>>>>>>> sound server model would greatly limits the design and usage of
>>>>>>> csound. A server model can be added on top of a synchronous API, as
>>>>>>> can an asynchronous model.  The design must instead be layered.  The
>>>>>>> internal core of csound should be simple; all other things can then be
>>>>>>> built on top of it.  Adding things like JSON or OSC as a primary
>>>>>>> interface into the core is, in my opinion, limiting.
>>>>>>>
>>>>>>> However, there is no reason a server model could not and should not be
>>>>>>> made.  Rather, a server application can be done that it itself uses
>>>>>>> the same core Csound API, and this application can be distributed with
>>>>>>> Csound.  It could be made to communicate via OSC, JSON, etc., and can
>>>>>>> be designed to use the API to internally communicate with an instance
>>>>>>> of Csound, as well as handle communications with a client application.
>>>>>>>
>>>>>>> In essence, by minimizing what Csound does in its core, we effectively
>>>>>>> increase its usability. We start with the design that has the least
>>>>>>> amount of latency and can introduce unknowns like network protocols on
>>>>>>> top of it.  We can embed Csound directly or decide to use it in a
>>>>>>> separate process.  (This is especially important for mobile
>>>>>>> applications, where interprocess communication is prohibited or very
>>>>>>> limited).
>>>>>>>
>>>>>>> Thanks,
>>>>>>> steven
>>>>>>>
>>>>>>> On Tue, Apr 24, 2012 at 3:27 PM, Jacob Joaquin  wrote:
>>>>>>>> I'm in the process of writing Python prototype scripts and pseudocode
>>>>>>>> in attempt to gain a better understanding of what is needed to build a
>>>>>>>> better bridge between a lower level synth engine to a higher level
>>>>>>>> language for users. With the right bridge, I believe we could simply
>>>>>>>> the process of integrating Csound into higher level languages and even
>>>>>>>> creating a "Csound Lite/Logo" type language.
>>>>>>>>
>>>>>>>> In particular I strongly believe that a sound server model, similar to
>>>>>>>> the one employed by SuperCollider, could drastically improve the
>>>>>>>> orc/sco paradigm. Imho, the scsynth/sclang and the orc/sco paradigms
>>>>>>>> are already conceptually very similar. The difference is that
>>>>>>>> SuperCollider has great communication between the two. For example, it
>>>>>>>> isn't one-way. This is just for the orc/sco, I'm not including the
>>>>>>>> Csound API in this.
>>>>>>>>
>>>>>>>> If Csound6 supported JSON, and not just peripherally, it would be much
>>>>>>>> easier for users to do things at a higher level. I'm going with JSON
>>>>>>>> mostly because it's very lightweight and well supported, and maybe a
>>>>>>>> good match for the Csound6 API.
>>>>>>>>
>>>>>>>> For example. Let's say every unit generator in Csound6 had a
>>>>>>>> corresponding JSON data structure that throughly described its
>>>>>>>> interface, including human readable descriptions of what the unit
>>>>>>>> generator does and descriptions of each input/output. A structure like
>>>>>>>> this could be used by a language like Python to create automatically
>>>>>>>> generate classes for everything.
>>>>>>>>
>>>>>>>> Then inside inside Python, users could describe graphs / design
>>>>>>>> instruments without even considering what native Csound syntax looks
>>>>>>>> like. When it's time to compile an orchestra, or modify the current
>>>>>>>> synth runtime if Csound6 supports dynamic loading, unloading, Python
>>>>>>>> wraps it up in JSON, sends it to the server. This could potentially be
>>>>>>>> a near seamless process for users.
>>>>>>>>
>>>>>>>> Being JSON, the same principle could be applied to other languages,
>>>>>>>> like javascript or ruby.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Jake
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Apr 24, 2012 at 4:44 AM, Richard Dobson
>>>>>>>>  wrote:
>>>>>>>>> I certainly don't wish to put a damper on any of these discussions, and
>>>>>>>>> I see all of the attractions of a 'common language" for engine and
>>>>>>>>> "pieces", but I still very much value the distinctiveness of the
>>>>>>>>> synthesis language and the scoring language(s), including in the
>>>>>>>>> latter's simplest form of note list, and in my own usage it very often
>>>>>>>>> arises that a common orchestra is used with many alternative scores,
>>>>>>>>> whether bundled in a csd or written separately. I hope that the
>>>>>>>>> principle of the orchestra and score is not consigned to the waste bin
>>>>>>>>> of history as being in any way obsolete or deprecated. Conceptually it
>>>>>>>>> still has all the merits and virtues it always had. Whatever changes are
>>>>>>>>> made, I hope the identity, character and idiom of Csound is retained,
>>>>>>>>> and that Csound6 does not become (yet) another attempt to change the
>>>>>>>>> language into something else.  There will never come a time when it is
>>>>>>>>> not possible to invent new languages!
>>>>>>>>>
>>>>>>>>> I remain of the opinion that Csound is already very well placed to be,
>>>>>>>>> so to speak, a backend for higher-level languages (not least, SAOL) that
>>>>>>>>> can do whatever it is people want to do, and that, as ever, backwards
>>>>>>>>> compatibility remains a founding principle.
>>>>>>>>>
>>>>>>>>> With the new parser in place, there is also plenty of scope to consider
>>>>>>>>> perhpas in the longer term  a formal reimplementation using whatever
>>>>>>>>> modern programming techniques and languages are presently in fashion. I
>>>>>>>>> am as it happens interested in the broader aspects of educational
>>>>>>>>> outreach, where a reduced and simplified language model ("Csound Lite")
>>>>>>>>> might be of great value in schools as a way to introduce music
>>>>>>>>> computing, supporting the new UK initiatives for CS in schools, for
>>>>>>>>> example; aiming at, say, Year 5s onwards.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Richard Dobson
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Live Security Virtual Conference
>>>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> codehop.com | #code #art #music
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Live Security Virtual Conference
>>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Live Security Virtual Conference
>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>> Dr Victor Lazzarini
>>>>>> Senior Lecturer
>>>>>> Dept. of Music
>>>>>> NUI Maynooth Ireland
>>>>>> tel.: +353 1 708 3545
>>>>>> Victor dot Lazzarini AT nuim dot ie
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> codehop.com | #code #art #music
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> Dept. of Music
>>>> NUI Maynooth Ireland
>>>> tel.: +353 1 708 3545
>>>> Victor dot Lazzarini AT nuim dot ie
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> codehop.com | #code #art #music
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
codehop.com | #code #art #music

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/lis