| Thanks for your responses. I think this is a very constructive discussion.
>Every once in a while I've thought about all the synthesis systems out
>there and I keep finding that Csound has many of the important parts
>"right".
I have mixed feelings about this. I don't share the feeling that Csound got so many things 'right,' but I agree with you (we have discussed this between ourselves) that Csound has retained a valuable focus on off-line rendering/non-real-time performance, and that it has the biggest opcode toolkit.
>I don't see a need for a new synthesis system from scratch,
>but a new engine will really open up a whole lot of things in my
>opinion that writing a new system might cover, but it would have the
>benefit of all of the existing opcodes and history.
I certainly agree with that. It's what has kept me from finishing any of my prototype systems, and always going back to Csound to actually make music.
>-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.
Adding the ability to write Csound instrument definitions in scripting code is, for me, functionally equivalent to writing a new system from scratch. If we can do this, motivation for a new system pretty much goes away, except for the sheer desire to tinker.
If opcodes and Csound instruments can be written in a language such as Java or C#, then your remarks below about these languages would also apply to Csound, even further reducing any need for a new system.
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. The code will shrink maybe 50% and will speed up by 5% to 15%. This is based on real experience. It can be done by taking the EXISTING STRUCTS and adding the EXISTING FUNCTIONS as member functions to them and compiling them with the C++ compiler. There is no need to change all the fields and rewrite all the functions. Again, this is based both on experience with my C++ OpcodeBase class, which is what I use for writing plugin opcodes, as well as experience adapting other C code to C++. Then some of the functions can be rewritten or refactored -- AFTER being ported to C++.
I know that some Csound developers do not care for C++, but my experience with C++ as compared with C, and I have worked for years for pay with both, is very positive. I find that C++ code is much easier to refactor and maintain, partly because of tool support. For example, there is some support for refactoring in the Eclipse C++ development environment.
(II) Declare all "engine" structs and functions in one header file. Declaring all the main stuff in one file makes it much easier to change and refactor the code.
(III) Define all "engine" functions in one source file. Again, defining all the main stuff in one file makes it much easier to change and refactor the code.
(IV) In order to enable Csound for parallel performance on multicore machines, several design patterns should be kept in mind. They are: "parallel for", "parallel reduce", and "parallel pipeline." In parallel for, an existing loop is divided up into chunks that execute independently. This requires that each iteration of the loop be data independent of the other iterations. In parallel reduce, parallel for first occurs, then the results of the otherwise independent iterations are 'reduced' or joined together, which may require data synchronization. In parallel pipeline, different stages of processing are executed independently.
The pattern that applies most naturally to Csound is parallel reduce. The main application would be that each running instrument instance could execute independently, but then the outputs of the instances would be reduced by summing them in synchronized code. For this to happen in Csound:
(A) The instances must be data independent respecting their INPUTS (pfields, some of the engine fields that instances access, some opcode returns) outside of the reduce stage of the pattern. This, in turn, can be guaranteed if the inputs are either (i) read-only, or (ii) copies by value (so that changing an input in one instance does not change the same input in another instance).
(B) The instances must be data independent respecting their OUTPUTS (output opcodes). This can be guaranteed if outputs are copies by value in the 'for' part of the pattern, which are then summed or otherwise reduced in a synchronized block of code in the 'reduce' part of the pattern.
(C) The list of instances must be a random access collection, i.e. an array or vector, not a linked list as it currently is. This is required in order to efficiently divide up the list for iteration in separate threads. My experience is that std::vector<> runs about as efficiently as Csound's hand-coded linked lists.
Can anyone identify applications in Csound for plain parallel for, or for parallel pipelines?
(V) Change to garbage collected memory management. GC could optionally be turned off during performance. The Boehm memory manager is open source and widely used. Almost all memory bugs in Csound go away, and live performance might even become more efficient when GC is turned off.
(VI) I would directly embed Lua into Csound as the 'scripting language' of choice. It is essentially as powerful as Python, is becoming more widely known, works with SWIG, and is by far the smallest, lightest-weight general purpose programming language. Plus, Lua builds and runs on everything.
(VII) But I would also make sure that there are wrappers, not only for the API but also for dynamic instrument creation, in Java and/or C#.
If these changes were implemented, Csound would become the leading software sound synthesis system, not only in terms of opcode wealth, but also in terms of raw performance (current computers already come with more than 1 CPU and the number will double every year or so) and even of software engineering.
Hope this sparks some more constructive discussion, and I hope you other Csound developers chime in.
Best,
Mike
-------------------------------------------------------------------------
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 |