I am not so sure that in 3 years, Csound would be obsolete
if we do not adopt engine-level parallelism. At the moment,
there are no systems around that can rival Csound's
extensive signal processing capababilities. For this reason
alone, I can't see any that happening. No matter how clever
things like
CSL (and the SndObj library, for that matter, if we are
talking about frameworks), they cannot begin to reach
the wealth of processing seen in Csound.

My 5 cents over and done with, I must say that I am very
interested in parallel implementations of Csound, having
had some experience with MPI kind-of-thing, coarsely
grained parallelism on Beowulf-like machines. The question
is at where to aim this; Csound as is now can be
parallelised
both at thread-level and process-level. Multiple instances
can be run into one 'collecting' one which can then do audio
IO; MPI-based systems can be built, distributing the
processing
into separate orchestras and instances etc, the same with
multi-threaded programs. The fun begins when we want to
load-balance and try to make the whole thing as efficient as
possible. This kind of parallelism is possible because it is
host-driven and the API supports it.

Now if we want to make the Csound engine parallel, then
the first question is which problems are truly parallel
and which are not. Are we going to implement language
facilities for parallel evaluation and then leave the
problem to the user? Are we going to optimise ORCs to
be made parallel? It is fine to say we want to do this,
but we need a clear roadmap.

But I think we need a new parser before any of this is
done. I would love to help, but I am little out of my
depth when it comes to lexers and stuff like that.

Victor
>
> Michael Gogins wrote:
> .
> >> -build instruments piece by piece in any language that
> uses csound  >> -make Csound parallizable (well, makes it
> > easier to do so!)
> >
> > These are the critical elements.
> .
> > At some point in the not too distant future, 3 years at
> > the LATEST, if Csound cannot run parallel instruments,
> > it will be obsolete. Some of the C++ synthesis
> > frameworks (such as the Create Signal Library) have
> > already begun to address parallel processing.
> > Let us suppose that we are refactoring Csound's
> > internals. My recommendations would be:
> >
> > (I) Rewrite the kernel and basic data structures in C++
> > and use the standard C++ library template collections to
> > manage lists, strings, and so on.

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