This sounds like we are moving Csound towards being a full scripting
language.  I like the idea of a synthesis language with a little more
richness than Csound (obviously, SAOL already fits this bill quite well) ,
but would be a dramatic change to the nature of Csound - perhaps too much?
How far can it be taken before we end up reinventing CMIX? (What are the
odds that one day we can embed Csound in a web page?)

Gabriel Maldonado wrote:

> With respect of adding new features to the ORC language, I suggest the
> following things:
>
> 1) the possibility to implement multi-arguments functions and
> subroutines that can be written directly in the orc code with following
> form:
> ;****CALLING A FUNCTION (named 'anyfunc1' in this example)
> a1    oscili    anyfunc1(a2,a3,a4) * kamp, anyfunc2(a3,a4,a5),  1
>
> ;**** BODY OF A FUNCTION
>          func      anyfunc1(aparm1,kparm2,iparm3,kparm4)
> avalue   =         aparm1+sqrt(parm2)
> avalue2  oscili    avalue, kparm2 ,iparm3
>          areturn   avalue2 * kparm4
>          endfunc
>
> ;**** CALLING A SUB (named 'anysub' in this example)
> aoutarg1, aoutarg2   anysub      ainarg1,ainarg2, kinarg3
>
> ;**** BODY OF A SUB
>           sub      anysub(aoutarg1,aoutarg2,ainarg1,kinarg2,inarg3)
> aoutarg1  oscili   1,ainarg1,1
> aoutarg2  oscili   1,kinarg2,1
> aoutarg3  oscili   1,inarg3,1
>           endsub

I'm not sure what you means by 'compiled as inline', given that Csound
doesn't compile anything,as such. Are these really macros?
What would be the necessary restrictions on these? For example, presumably
the oscili instances retain their internal state between calls, i.e are
effectively static objects. So presumably they are not re-entrant.  How
would they behave if control occasionally jumped past them? Presumably these
would not be global functions, but within the scope of an instrument? Could
the same function be called more than once in the same argument list?  eg:
        a1    oscili    anyfunc1(a2,a3,a4) * kamp, anyfunc1(a3,a4,a5),  1)

A function which only allowed arithmetical statements might be a useful
inclusion - it could have global scope. Also a function which allowed local
variables, so that some private modification of a krate argument could be
made at arate, might be useful. The local variable could have an initializer
which is reset at each krate step (or integer multiple).

> 3) standard structured languages conditional flow of control
> statements:if...elseif...else...endif,
> switch...case...default..endswitch,

Someone will surely want these at arate as well as i- and krate. That is a
lot of keywords!In a switch, would all the 'cases' need to be at the same
rate?  There must be many examples where the direct transfer of procedural
constructs to Csound is complicated by the issue of multiple execution
rates.

At the moment, the distinction betweeen control statments such as kgoto and
synthesis opcodes is handled deep within the code - they all appear as
opcodes in entry.c.  Would it be feasible to  make the distinction explicit,
by separating out Csound keywords (instr, endin, label,reinit, etc) from the
audio opcodes? It is not clear to me at the moment which opcodes apart from
the first three could be explicitly built into the parser, while keeping the
rest of the code as it is.

> 4) semi-global variables, shared within several instances of the same
> instr during the performance, but not within instrs of different number.

Yes! This would arise easily in a C++ implementation; they would be 'static'
variables for the instrument. I have long felt the need to have some means
of preserving context across instrument calls - for example, to have the
equivalent to the 'np' and pp' score fields, in the instrument. What would
everyone feel about an extra qualifier for an instr to make it monophonic?
It could be as simple as  " instr 1 mono" - this would remove the need for
much special jiggery-pokery in the score.

> SCO language additions:

One factor which needs to be allowed for is the cscore tool, which draws on
quite a number of the core Csound functions.  The sco parser would have
obvious uses here, and itself would need to be called within Csound after
the call to cscore(). Is any one on the list an active cscore programmer?


I can see that posts on this topic are going to be very long!


Richard Dobson