yes, but that is way limited if compared to Csound.  The problem is that
once you become used to csound, it is very hard to move to any other
system, as you soon start missing things you had there. Nothing compares
to Csound in availability of unit generators.

At 15:29 24/03/2006, you wrote:
>Steven, you may be interested in ChucK, an on-the-fly audio processing 
>language that does the midst-of-performance reprogramming you mention.
>
>Are you talking about Extended Csound, or some other newer project of 
>Barry Vercoe's?
>
>Regards,
>Mike
>
>-----Original Message-----
> >From: Steven Yi 
> >Sent: Mar 24, 2006 2:36 AM
> >To: csound@lists.bath.ac.uk
> >Subject: Re: [Csnd] The future of computer music? (was Re: [Csnd] The 
> future of winsound)
> >
> >Hi All,
> >
> >On 3/23/06, Anthony Kozar  wrote:
> >> I would say that Csound 5 is more like the future of computer music 
> software
> >> INFRASTRUCTURE.  It is a modular, reusable, programmable synthesis engine
> >> that can be adapted in hundreds of different ways.
> >
> >I agree with this, but I think there is more to do to further push
> >Csound's possibilities for developers (which I'd like to differentiate
> >from Csound as tool for music making and expressing musical ideas,
> >which it already does amazingly, in my opinion). More thoughts below.
> >
> >> For instance, someone could create a GUI effects processor with dozens of
> >> preset effects and graphical controls for editing their 
> parameters.  Csound
> >> could be the engine underneath of it all, but the user would never see a
> >> line of Csound code.  (Cecilia provides this ability with its built-in
> >> modules I think).
> >
> >blue has this capacity in recent releases for user-definable GUI
> >effects processors, as well as GUI note generators (ObjectBuilder,
> >which can use python or any external program such as Perl, nGen,
> >CMask, etc. as the scripting language), and GUI instruments
> >(BlueSynthBuilder).  Using all of those together with the built-in
> >objects like the PianoRoll and PatternObject, one doesn't need to ever
> >see a line of Csound code (well, maybe just a little bit here and
> >there).  Even with all of that, you still have the capacity to do all
> >the standard Csound things within the environment (write note
> >statements, code instruments in csound code, etc.).
> >
> >Where I see real possibilities for furthering the design of Csound
> >will come to some degree with the work that goes into the new parser
> >and abstracting out the individual functions that will allow closer
> >fine-grained modification of instruments and notes in memory.  Right
> >now, Csound parses an orchestra and sets things up in memory which is
> >expected to be run as-is: you can perform, rewind, and perform the
> >same things again.  As a program designer, one could possibly design
> >one's program to not use Csound SCO but to only feed in realtime and
> >to sync playing those realtime events from the host with the
> >performance time of the engine.  Then one could keep the instruments
> >in memory and have dynamic notes (i.e. change a script to regenerate
> >notes on the fly while a Csound run is running).  However, one can not
> >dynamically modify the flowgraph of opcodes in an instrument, so on
> >the fly changes to an instrument is impossible.  One currently has to
> >reparse a whole orchestra to do that, and that can be a length
> >process, as I recently realized when working with some large
> >soundfonts and the fluidsynth opcodes.  As a program designer then, it
> >would be great to be able to dynamically replace single instruments
> >within an orchestra at least, while being able to dynamically swap out
> >opcodes would be great.  These things I think should be able to be
> >done if the backend of the parser is done with very fine-grained
> >functions.
> >
> >Just a note though that these thoughts are really only relevant to
> >program designers and programs designed to use Csound and do not
> >affect Csound usage.  By that I mean that what users see as Csound
> >would remain the same, but the changes would allow for programs to be
> >made such that Csound stays more active in memory and so could help
> >users do their work faster if they can try out changes more quickly.
> >
> >I'd also like to see a parallel-processing Csound in some form,
> >whether it is multi-processor solution with shared memory on a single
> >machine, a host/nodes situation that you see in some commercial
> >programs like Logic, or a clustered computing grid.  Any of these
> >would be nice to eventually have in an open source and freely
> >available Csound (I doubt there will be any chance in the future I'll
> >have access to Barry Vercoe's multiprocessor Csound anytime soon).
> >
> >steven
> >--
> >Send bugs reports to this list.
> >To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>
>
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

Victor Lazzarini wrote:
> yes, but that is way limited if compared to Csound.

Depends on how you look at it.

Chucks language is far more elegant and you can do extremely complicated 
stuff in few lines of code. I needed dynamic voice allocation and 
implemented it in a day in chuck. Part of this included writing a stack 
(LIFO) class, which was piece of cake. I wouldn't wanna look at the 
spaghetti that would be a csound implementation of a stack.

That said I'm still using csound as my main synth, mainly because of 
effeciency.

-- 
peace, love & harmony
Atte

http://www.atte.dk

But  depending on what you are doing, dynamic voice allocation in
Csound can be done by just sending (realtime or otherwise) events into it.

Chuck does not even begin to touch the richness in sound synthesis and
processing allowed by csound. In fact, as far as I can see it does not
even compare to SuperCollider (or PD for that matter).

In the battle of so-called 'elegance' and sound-production, I will always
look for the latter. But then again that's the way I was schooled and
don't expect anyone to feel that way (and that's why I use csound...)

Victor

At 18:09 24/03/2006, you wrote:
>Victor Lazzarini wrote:
>>yes, but that is way limited if compared to Csound.
>
>Depends on how you look at it.
>
>Chucks language is far more elegant and you can do extremely complicated 
>stuff in few lines of code. I needed dynamic voice allocation and 
>implemented it in a day in chuck. Part of this included writing a stack 
>(LIFO) class, which was piece of cake. I wouldn't wanna look at the 
>spaghetti that would be a csound implementation of a stack.
>
>That said I'm still using csound as my main synth, mainly because of 
>effeciency.
>
>--
>peace, love & harmony
>Atte
>
>http://www.atte.dk
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

Victor Lazzarini wrote:
> But  depending on what you are doing, dynamic voice allocation in
> Csound can be done by just sending (realtime or otherwise) events into it.

I know...

> Chuck does not even begin to touch the richness in sound synthesis and
> processing allowed by csound. In fact, as far as I can see it does not
> even compare to SuperCollider (or PD for that matter).

Agreed. We must remember that 1) chuck has a different focus 
(on-the-fly-programming) and 2) is young (very young compared to csound).

> In the battle of so-called 'elegance' and sound-production, I will always
> look for the latter.

I agree, this is also why I use csound. But the reason I'm beginning to 
work on my python-csound-environment is in a way due to the lackings of 
csound. I love coding in emacs, but there are simply things that are so 
heavy or so besides-csounds-focus, that something else is needed.

I've never thought about it this way before, but some people in this 
thread hint at one future scenario. A scenario where csound workds as a 
low-level, high performing number-cruncher that's gonna be the backbone 
of a variety of systems with "fancier" frontends, be it GUIs or 
something else. That might not be so far from the truth...

-- 
peace, love & harmony
Atte

http://www.atte.dk

> In the battle of so-called 'elegance' and sound-production, I will always
> look for the latter. But then again that's the way I was schooled and
> don't expect anyone to feel that way (and that's why I use csound...)

And there is also efficiency. Csounds inflexibility is part and parcel
of it's close to the machine architecture, which means that if you don't
mind coding all your options ahead of performance ( as one would
normally do building a synth in hardware for example ) the performance
increase is significant. Glyn and I did a PD/csound shoot out a couple
of years ago for a few tasks and it wasn't even close.

Iain