> So, following up on our discussion on computer music languages, I
> was wondering how far we are from having a python environment
> that let's me build an instrument at runtime from python source.

I wrote a working prototype in Python last year that shows how
instrument templates might work in Csound. Users would write generic
instrument templates instead of instruments, import them into new
projects, and then create instrs and graphs from them. Not quite what
you're getting at, but its something sorta along those lines. The idea
was to keep Csound looking like Csound, while adding capabilities that
would allow easier instrument sharing.

The Package
http://www.thumbuki.com/slipmat/Slipmat0.0.1alpha.zip

The included manual goes into much greater detail. The tutorial
section is probably the best place to start.

Best,
Jake

Python is not necessarily the way to go. Lua is probably a better
choice as it appears to offer significantly higher performance and
thinner "glue" code, especially with the LuaJIT just in time compiler
for x86.

As far as Csound itself is concerned, the most important missing piece
is the ability to insert an "instrument template" during performance.
The ability to insert opcodes during performance, actually, either
already exists (though I haven't actually tried it), or at least would
be much easier to do. It would probably be best to recode the existing
opcode list as a map with thread safety, so that opcodes can be be
inserted and deleted at any time without hiccups.

In reality, if you create an instrument that is just a shell for an
opcode that does all the work, perhaps we are not that far off from
this.

There is nothing to prevent such a dynamic opcode definition from
being written in Python or Lua or any other language. Similarly, it
should be fairly easy to wrap all or almost all existing opcodes in
the same language.

Then instead of recompiling the instrument definition during
performance, you could rewrite your opcode script and it would be
recompiled during performance and be called by the instrument with
probably rather similar results.

At some point, I may create a Lua opcode or small set of opcodes as a
starting point for this idea. Ultimately this could have the effect of
smuggling a whole new software synthesizer into Csound, one that would
use Csound for note and event dispatching, and for I/O with the outer
world, but otherwise enable writing instruments in a higher level
language.

But this all seems a bit clunky and hacky. It believe it would be best
to design a new music language from scratch, but one that could easily
incorporate unit generators written in other languages, and that would
support live coding from the get-go.

Regards,
Mike

On Fri, Apr 9, 2010 at 3:32 PM, Anthony Palomba  wrote:
> So, following up on our discussion on computer music languages, I
> was wondering how far we are from having a python environment
> that let's me build an instrument at runtime from python source.
>
> I assume in the very least we would need a python interface
> for csound opcodes and a way to build a signal path that connects
> these opcodes at runtime. This would make csound pretty much like
> SuperCollider! Add to that all the various python packages
> for numerical analysis and visualization and you have a pretty
> formidable synthesis language environment.
>
> So my question for the csound elders is, how far are we from having
> something like this? Are there huge architectural changes that need
> to happen in order to enable this?
>
>
>
> Anthony
>

I will take a close look at this.

Regards,
Mike

On Fri, Apr 9, 2010 at 3:50 PM, Jacob Joaquin  wrote:
>> So, following up on our discussion on computer music languages, I
>> was wondering how far we are from having a python environment
>> that let's me build an instrument at runtime from python source.
>
> I wrote a working prototype in Python last year that shows how
> instrument templates might work in Csound. Users would write generic
> instrument templates instead of instruments, import them into new
> projects, and then create instrs and graphs from them. Not quite what
> you're getting at, but its something sorta along those lines. The idea
> was to keep Csound looking like Csound, while adding capabilities that
> would allow easier instrument sharing.
>
> The Package
> http://www.thumbuki.com/slipmat/Slipmat0.0.1alpha.zip
>
> The included manual goes into much greater detail. The tutorial
> section is probably the best place to start.
>
> Best,
> Jake
> --
> The Csound Blog - http://csound.noisepages.com/
> Slipmat - http://slipmat.noisepages.com/
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>



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


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi Anthony,

On the dev list over the past year or two we've discussed dynamic
instrument building and requirements for it.  The big part is changing
how Csound allocates memory for instrument instances and not erasing
variable names after compilation.  I think most of the issues to work
through have been discussed at one point or another, but just no one
has had time to investigate.

Ideally, I think we need to refocus to finish out the new parser
first, then engine modifications next, as the first makes the second
much easier.

steven

On Fri, Apr 9, 2010 at 3:32 PM, Anthony Palomba  wrote:
> So, following up on our discussion on computer music languages, I
> was wondering how far we are from having a python environment
> that let's me build an instrument at runtime from python source.
>
> I assume in the very least we would need a python interface
> for csound opcodes and a way to build a signal path that connects
> these opcodes at runtime. This would make csound pretty much like
> SuperCollider! Add to that all the various python packages
> for numerical analysis and visualization and you have a pretty
> formidable synthesis language environment.
>
> So my question for the csound elders is, how far are we from having
> something like this? Are there huge architectural changes that need
> to happen in order to enable this?
>
>
>
> Anthony
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 10/04/2010, at 6:15 AM, Michael Gogins wrote:

> Python is not necessarily the way to go. Lua is probably a better
> choice as it appears to offer significantly higher performance and
> thinner "glue" code, especially with the LuaJIT just in time compiler
> for x86.
...
Hi Anthony, Mike, Steven, all,

One of the advantages of implementing in Python, though, is that it is  
more easily integrated into a broader composition framework that  
includes other tools (incl. other 3rd party) etc etc. Unless of course  
one has a particularly masochistic desire to re-engineer the whole  
environment - and not be concerned with the size of an eventual user  
base.
I know I do bang on about this issue. (I wonder how all those people  
who put a significant compositional effort into ChucK now feel about  
its apparent development demise.) Speed-wise, Lua might be perfectly  
beautiful tool, but there are ways of making Python pretty fast. Given  
the larger user base, and thus the greater chance of a more  
sustainable project with a larger user (and possibly development)  
base, the more seamless integration w. existing python interface to  
csound etc, I'd want to see details of the significant advantages of  
going broader.

On the other hand, if sustainability is not a concern, it could be  
written in lots of different tools - even assembler!

An interesting project....

D.


________________________________________________
Dr David Worrall.
- Experimental Polymedia:	  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au








Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I would disagree with either Python or Lua and think the way forward
is to focus on making the core of Csound much cleaner as an API and
library.  After that, bindings allow anyone to do anything with it.  I
think adding things like Python or Lua as a requirement internally
would make Csound more brittle.  With a more open engine design, one
can opt to do an entire piece in Python or Lua, from score generation
to synthesis, but the engine would not be tied to either language.  I
think that way is best for long-term art works to survive.

Live coding too would be manageable with a new engine.

As for instrument templates, I know John put in a feature to delete
instrument definitions already and I think insert them as well.  The
missing parts are parsing an instrument, but if the engine is redone,
after the parsing process it won't leave Csound in a fixed state, it
could allow reparsing with the same Csound object to allow replacing
an instrument, etc.  It'd be functionally like how we send sco text to
Csound, but rather we could send orc text.  (Ends up being similar to
sending SynthDef's to SuperCollider I believe.)

I'm currently wondering what's the path forward.  I am thinking maybe
better to create a new engine from scratch that introduces bindings to
external languages from the start.  From there, build it up as one
would like to see an audio engine, and slowly incorporate the Csound
parts back in until feature compatibility is complete.

steven

On Fri, Apr 9, 2010 at 4:15 PM, Michael Gogins  wrote:
> Python is not necessarily the way to go. Lua is probably a better
> choice as it appears to offer significantly higher performance and
> thinner "glue" code, especially with the LuaJIT just in time compiler
> for x86.
>
> As far as Csound itself is concerned, the most important missing piece
> is the ability to insert an "instrument template" during performance.
> The ability to insert opcodes during performance, actually, either
> already exists (though I haven't actually tried it), or at least would
> be much easier to do. It would probably be best to recode the existing
> opcode list as a map with thread safety, so that opcodes can be be
> inserted and deleted at any time without hiccups.
>
> In reality, if you create an instrument that is just a shell for an
> opcode that does all the work, perhaps we are not that far off from
> this.
>
> There is nothing to prevent such a dynamic opcode definition from
> being written in Python or Lua or any other language. Similarly, it
> should be fairly easy to wrap all or almost all existing opcodes in
> the same language.
>
> Then instead of recompiling the instrument definition during
> performance, you could rewrite your opcode script and it would be
> recompiled during performance and be called by the instrument with
> probably rather similar results.
>
> At some point, I may create a Lua opcode or small set of opcodes as a
> starting point for this idea. Ultimately this could have the effect of
> smuggling a whole new software synthesizer into Csound, one that would
> use Csound for note and event dispatching, and for I/O with the outer
> world, but otherwise enable writing instruments in a higher level
> language.
>
> But this all seems a bit clunky and hacky. It believe it would be best
> to design a new music language from scratch, but one that could easily
> incorporate unit generators written in other languages, and that would
> support live coding from the get-go.
>
> Regards,
> Mike
>
> On Fri, Apr 9, 2010 at 3:32 PM, Anthony Palomba  wrote:
>> So, following up on our discussion on computer music languages, I
>> was wondering how far we are from having a python environment
>> that let's me build an instrument at runtime from python source.
>>
>> I assume in the very least we would need a python interface
>> for csound opcodes and a way to build a signal path that connects
>> these opcodes at runtime. This would make csound pretty much like
>> SuperCollider! Add to that all the various python packages
>> for numerical analysis and visualization and you have a pretty
>> formidable synthesis language environment.
>>
>> So my question for the csound elders is, how far are we from having
>> something like this? Are there huge architectural changes that need
>> to happen in order to enable this?
>>
>>
>>
>> Anthony
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

What do you mean?
On 9 Apr 2010, at 22:26, DavidW wrote:

> (I wonder how all those people who put a significant compositional  
> effort into ChucK now feel about its apparent development demise

and about Python: I also agree it has a much better prospect for  
development than other more 'fringe' languages...


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 10/04/2010, at 7:36 AM, Victor Lazzarini wrote:

> What do you mean?
> On 9 Apr 2010, at 22:26, DavidW wrote:
>
>> (I wonder how all those people who put a significant compositional  
>> effort into ChucK now feel about its apparent development demise
>
> and about Python: I also agree it has a much better prospect for  
> development than other more 'fringe' languages...
...
I've read a couple of comms recently which suggest this. On SC list, I  
think. and from www.kvraudio.com/forum/viewtopic.php?t=281079
> I would not suggest Chuck. While I have heard it is fairly simple to  
> use, it has a very small community, and last I heard, is no longer  
> being developed. Csound is continually being developed by MIT and  
> Berklee, so there won't be a lack of future support; Supercollider's  
> community is very passionate, though less organized, and I doubt  
> that Supercollider is going to stop being developed any time soon.

Also http://wiki.cs.princeton.edu/index.php/ChucK/Dev/DoThisNow
> ... HIGH PRIORITY....
> ... 	• This page was last modified 01:03, 19 July 2006.•

Anecdotal, I admit and I would be happy to be informed otherwise.   
Life is far too short to develop another mountain-climbing ice-pick  
when the savannas are still in such drought.


D.

________________________________________________
Dr David Worrall.
- Experimental Polymedia:	  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au








Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 10/04/2010, at 8:01 AM, Victor Lazzarini wrote:

> I think the question here is not make Csound into SC, but use some  
> features presented by SC which might make Csound more flexible. Note  
> that these features are not exclusive to SC (PD for instance, also  
> implements them).
>
> Victor
Yes. SCsynth is fabulous and sounds different to csound. SClang, on  
the other hand? I can't be bothered converting thousands of lines of  
code into a single app. environment - let alone develop new tools  
which SClang doesn't have but are out there and readily available in  
the Python community.  I address SCsynth via OSC (which SClang does  
too) but from python for the same reasons i mentioned b4.

David.

> On 9 Apr 2010, at 22:39, Andrea Valle wrote:
>
>> I know I'm touching a hot point. But, really, I'm just curious.
>> I can understand the idea of maintaining Csound as it is with  
>> respect to a large community of users.
>> I cannot understand clearly the ration behind its transformation in  
>> something like a pseudo-(or post-)SuperCollider.
>>
>> In that case, why do not stick to SuperCollider?
>> Or the idea is addressing some issue which is not addressed or  
>> (badly addressed) by SuperCollider?
>>
>> Best
>>
>> -a-
>>
>>
>>
>>
>> On Apr 9, 2010, at 11:31 PM, Steven Yi wrote:
>>
>>> I would disagree with either Python or Lua and think the way forward
>>> is to focus on making the core of Csound much cleaner as an API and
>>> library.  After that, bindings allow anyone to do anything with  
>>> it.  I
>>> think adding things like Python or Lua as a requirement internally
>>> would make Csound more brittle.  With a more open engine design, one
>>> can opt to do an entire piece in Python or Lua, from score  
>>> generation
>>> to synthesis, but the engine would not be tied to either  
>>> language.  I
>>> think that way is best for long-term art works to survive.
>>>
>>> Live coding too would be manageable with a new engine.
>>>
>>> As for instrument templates, I know John put in a feature to delete
>>> instrument definitions already and I think insert them as well.  The
>>> missing parts are parsing an instrument, but if the engine is  
>>> redone,
>>> after the parsing process it won't leave Csound in a fixed state, it
>>> could allow reparsing with the same Csound object to allow replacing
>>> an instrument, etc.  It'd be functionally like how we send sco  
>>> text to
>>> Csound, but rather we could send orc text.  (Ends up being similar  
>>> to
>>> sending SynthDef's to SuperCollider I believe.)
>>>
>>> I'm currently wondering what's the path forward.  I am thinking  
>>> maybe
>>> better to create a new engine from scratch that introduces  
>>> bindings to
>>> external languages from the start.  From there, build it up as one
>>> would like to see an audio engine, and slowly incorporate the Csound
>>> parts back in until feature compatibility is complete.
>>>
>>> steven
>>>
>>> On Fri, Apr 9, 2010 at 4:15 PM, Michael Gogins >> > wrote:
>>>> Python is not necessarily the way to go. Lua is probably a better
>>>> choice as it appears to offer significantly higher performance and
>>>> thinner "glue" code, especially with the LuaJIT just in time  
>>>> compiler
>>>> for x86.
>>>>
>>>> As far as Csound itself is concerned, the most important missing  
>>>> piece
>>>> is the ability to insert an "instrument template" during  
>>>> performance.
>>>> The ability to insert opcodes during performance, actually, either
>>>> already exists (though I haven't actually tried it), or at least  
>>>> would
>>>> be much easier to do. It would probably be best to recode the  
>>>> existing
>>>> opcode list as a map with thread safety, so that opcodes can be be
>>>> inserted and deleted at any time without hiccups.
>>>>
>>>> In reality, if you create an instrument that is just a shell for an
>>>> opcode that does all the work, perhaps we are not that far off from
>>>> this.
>>>>
>>>> There is nothing to prevent such a dynamic opcode definition from
>>>> being written in Python or Lua or any other language. Similarly, it
>>>> should be fairly easy to wrap all or almost all existing opcodes in
>>>> the same language.
>>>>
>>>> Then instead of recompiling the instrument definition during
>>>> performance, you could rewrite your opcode script and it would be
>>>> recompiled during performance and be called by the instrument with
>>>> probably rather similar results.
>>>>
>>>> At some point, I may create a Lua opcode or small set of opcodes  
>>>> as a
>>>> starting point for this idea. Ultimately this could have the  
>>>> effect of
>>>> smuggling a whole new software synthesizer into Csound, one that  
>>>> would
>>>> use Csound for note and event dispatching, and for I/O with the  
>>>> outer
>>>> world, but otherwise enable writing instruments in a higher level
>>>> language.
>>>>
>>>> But this all seems a bit clunky and hacky. It believe it would be  
>>>> best
>>>> to design a new music language from scratch, but one that could  
>>>> easily
>>>> incorporate unit generators written in other languages, and that  
>>>> would
>>>> support live coding from the get-go.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Fri, Apr 9, 2010 at 3:32 PM, Anthony Palomba >>> > wrote:
>>>>> So, following up on our discussion on computer music languages, I
>>>>> was wondering how far we are from having a python environment
>>>>> that let's me build an instrument at runtime from python source.
>>>>>
>>>>> I assume in the very least we would need a python interface
>>>>> for csound opcodes and a way to build a signal path that connects
>>>>> these opcodes at runtime. This would make csound pretty much like
>>>>> SuperCollider! Add to that all the various python packages
>>>>> for numerical analysis and visualization and you have a pretty
>>>>> formidable synthesis language environment.
>>>>>
>>>>> So my question for the csound elders is, how far are we from  
>>>>> having
>>>>> something like this? Are there huge architectural changes that  
>>>>> need
>>>>> to happen in order to enable this?
>>>>>
>>>>>
>>>>>
>>>>> Anthony
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe csound"
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe csound"
>>>
>>
>> --------------------------------------------------
>> Andrea Valle
>> --------------------------------------------------
>> CIRMA - DAMS
>> Università degli Studi di Torino
>> --> http://www.cirma.unito.it/andrea/
>> --> http://www.myspace.com/andreavalle
>> --> http://www.flickr.com/photos/vanderaalle/
>> -->  http://www.youtube.com/user/vanderaalle
>> --> andrea.valle@unito.it
>> --------------------------------------------------
>> " This is a very complicated case, Maude. You know, a lotta ins, a  
>> lotta outs, a lotta what-have-yous."
>> (Jeffrey 'The Dude' Lebowski)
>>
>>
>>
>

________________________________________________
Dr David Worrall.
- Experimental Polymedia:	  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au








Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

> Anecdotal, I admit and I would be happy to be informed otherwise.  Life is
> far too short to develop another mountain-climbing ice-pick when the
> savannas are still in such drought.

SuperCollider has its own Symposium. That has to count for something:
http://supercollider.sourceforge.net/2010/supercollider-symposium-2010-september-berlin/

Anecdotally speaking, I see much more chatter about SC than Csound on
the net. And I search for Csound material almost daily; I generally
don't search for SC. Though I admit I have been researching SC as of
late.

Best,
Jake
-- 
The Csound Blog - http://csound.noisepages.com/
Slipmat - http://slipmat.noisepages.com/


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

As  does PD, and has had it for longer, but I don't think we are  
discussing the future viability of SC and PD. They are OK, as Csound  
(I guess). I think you're right that SC generates a lot of interest  
(as does PD). Csound has a good insertion on Universities, though (at  
least in Ireland and the UK).
But I agree with David that SClang is not that great.

Victor


On 9 Apr 2010, at 23:48, Jacob Joaquin wrote:

>> Anecdotal, I admit and I would be happy to be informed otherwise.   
>> Life is
>> far too short to develop another mountain-climbing ice-pick when the
>> savannas are still in such drought.
>
> SuperCollider has its own Symposium. That has to count for something:
> http://supercollider.sourceforge.net/2010/supercollider-symposium-2010-september-berlin/
>
> Anecdotally speaking, I see much more chatter about SC than Csound on
> the net. And I search for Csound material almost daily; I generally
> don't search for SC. Though I admit I have been researching SC as of
> late.
>
> Best,
> Jake
> -- 
> The Csound Blog - http://csound.noisepages.com/
> Slipmat - http://slipmat.noisepages.com/
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I agree with Anthony about using an existing language. Lua also has a
large user base and a large number of existing libraries for many
purposes. There is a very interesting comparison of programming
languages at http://shootout.alioth.debian.org which people can look
at to evaluate speed. LuaJit vs Python 3 for one core (neither Python
nor Lua are truly concurrent at this time):

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=python3

LuaJIT vs GNU C:

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=gcc

What this means is that LuaJIT might POSSIBLY be usable for audio DSP
in real time, whereas Python would definitely NOT be so usable. (Both
languages would be OK for off-line rendering.) Of course, the
benchmarks in the comparison are not about audio DSP and that
particular type of numerically intensive computation might not be so
favorable for LuaJIT.

Regards,
Mike


On Sat, Apr 10, 2010 at 12:44 AM, Anthony Palomba
 wrote:
> Well the intention here is not to turn Csound in to SuperCollider. We would
> not
> be replacing opcodes and tools that csound provides. We would be
> enhancing the users ability to access opcodes, create instruments and
> generate score events.
>
> I would like to make the argument that an existing language like python or
> lua be used as opposed to creating a new language. At this point
> python is a pretty developed object oriented language. There are very few
> things
> that a new language could really offer, other than novel syntax, that would
> warrant the development effort that it would take to get a new language to
> where
> python is. It think this is what Chuck tried to do, but in the end lacks the
> maturity to really build user base.
>
> Ultimately I want to keep using csound because I am already familiar with
> the
> various opcodes. I am not interested in learning a new set of tools. I just
> want to use my tools in a more flexible environment. I want a way to
> procedurally model my musical pieces and events within those pieces.
>
> I would also propose python because the vast amounts of existing source
> that is readily available. For example http://www.scipy.org/
> There are tons of great tools there that I would love to utilize.
>
> Again, I think this should definitely be put on the offical csound wish
> list.
>
>
>
>
> Anthony
>
>
>
>
>
> On Fri, Apr 9, 2010 at 5:56 PM, Victor Lazzarini 
> wrote:
>>
>> As  does PD, and has had it for longer, but I don't think we are
>> discussing the future viability of SC and PD. They are OK, as Csound (I
>> guess). I think you're right that SC generates a lot of interest (as does
>> PD). Csound has a good insertion on Universities, though (at least in
>> Ireland and the UK).
>> But I agree with David that SClang is not that great.
>>
>> Victor
>>
>>
>> On 9 Apr 2010, at 23:48, Jacob Joaquin wrote:
>>
>>>> Anecdotal, I admit and I would be happy to be informed otherwise.  Life
>>>> is
>>>> far too short to develop another mountain-climbing ice-pick when the
>>>> savannas are still in such drought.
>>>
>>> SuperCollider has its own Symposium. That has to count for something:
>>>
>>> http://supercollider.sourceforge.net/2010/supercollider-symposium-2010-september-berlin/
>>>
>>> Anecdotally speaking, I see much more chatter about SC than Csound on
>>> the net. And I search for Csound material almost daily; I generally
>>> don't search for SC. Though I admit I have been researching SC as of
>>> late.
>>>
>>> Best,
>>> Jake
>>> --
>>> The Csound Blog - http://csound.noisepages.com/
>>> Slipmat - http://slipmat.noisepages.com/
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>



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


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 10/04/2010, at 8:32 PM, Michael Gogins wrote:
...
> What this means is that LuaJIT might POSSIBLY be usable for audio DSP
> in real time, whereas Python would definitely NOT be so usable. (Both
> languages would be OK for off-line rendering.) ''

Well I wonder what I' been doing all these years - it seems to work  
for me. Maybe there is a swathe of homunculi running around in my  
machine passing bits between them and vocalising through the audio port.

Of course python talks to the audio port through audio libraries etc  
but so does pretty much everything else, Surely what we're talking  
about here is the user-interface level, in which case Python seems to  
work fine.

D.




________________________________________________
Dr David Worrall.
- Experimental Polymedia:	  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au








Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"