|
Riccardo Bianchini wrote:
> Dear Csounders,
> I've read very carefully all the stuff about Csound parser/Dynamic
> library
> linking and so on, and some questions arose in my mind:
>
> 1. Csound was born and is alive as a "standard" sound synthesis
> language, i.e., I can compose a piece and (assuming I didn't use
> external
> soundfiles for synthesis) send my orc/sco (usually less than 100 KByte)
> to the Csound community. Everybody can synthesize and listen to it (and
> possibly throw away resulting soundfile!). If we go on making
> "extensions", this could no more be true.
>
Well, it is only standard-ish - it was originally a rewrite in C of Music-11
(itself in an advanced evolutionary position along the MUSIC-N development
line), but still came out differently - it excludes the 'pipdef' and related
opcodes, which were recast as 'delay' etc.None of the additions have changed
existing opcodes in a way to break existing orcs, except where someone used
an output name which has become a new opcode. Whatever may come of the
brainstorming about parsers (which in principle is a purely internal issue
anyway), nothing that breaks existing code would be acceptable. Csound is
puiblic domain, and there a wide community of highly expert programmers
supporting and developing it, so, for better or worse, Csound is not going
to stand still. My opinion is that this is entirely for the better!
> 2. Are we trying to transform Csound in a commercial synth? Frankly, I
> don't understand WHY all those phisical modeling opcodes (marimba,
> vibraphone, agogobell etc.) are in Csound: admittedly, they make nice
> sounds... but a commercial synth (or even a *software* commercial synth)
> can do better. If someone likes to make marimba sounds, he'd better not
> use
> Csound.
>
Hmm - would those be ~free~ commercial synths, by any chance? :-)
> 3. New parser(s): OK for the orchestra: I'd like so much better program
> control structures: I could kill for something like:
>
> (Basic-flavour) (C flavour)
> If ka R kb then If ka R kb {
>
> ... ...
> ... ... }
> elseif ka R kc then else if ka R kc {
>
> ... ...
> ... ...
>
> or for a C-like "switch". But the score... please, don't! I think it's
> much better to use a general purpose programming language (I use
> Microsoft
> Visual Basic for quick & dirty works) to make whatever we like. I build
> myself a set of functions and subroutines that do most trivial jobs
> (parsing a Csound score and putting p-fields in arrays, writing a new
> score file and so on): and all this works very well to me.
> A score preprocessor could be a better idea, as it would not modify
> Csound itself.
>
> Do you think I'm too much conservative?
No, I don't; there is a strong, and obvious, case for preserving the
simplicity of Csound's quasi-assembler style. If a parser is successfully
developed, it might form the basis for experiments in ~carefully~ adding new
control structures which were truly useful, without turning Csound into
something else. But I suspect the main benefit would be in the ease of
developing supporting applications, such as an orchestra pre-processor,
which would meet many peoples needs, but would not change Csound itself.
I think a score preprocessor could be one of the most useful things to
emerge from
current explorations - especially one which can be incorporated into other
applications.
Obviously, there is scope for any amount of score-generating tools to be
developed, independent of Csound itself; but a parser/preprocessor which
could be called, for example, from Visual Basic (or even from a web page,
using Javascript) would cetainly assist in such developments.
There is also the matter of consistency with cscore itself, which possibly
several people are using?
Richard Dobson
|