| I think that any Csound change should increase its portability and,
above all, its efficiency in terms of speed. So I'm not completely sure
that a total C++ port of Csound is the best idea. I think it is better
to keep the critical parts of code in C. Also, some time ago somebody
observed that C++ language is not a real standard, at least until now.
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
The difference beetween functions and subs is that function can be
called from within an expression and allow only one output argument
implicitly sent to the expression context. Note that the opcodes
areturn, kreturn and ireturn will decide the type of return value of a
func.
Subs allow more output arguments but should be called in its own line of
code, they don't use 'areturn' 'kreturn' or 'ireturn'.
All functions and subs should be compiled as inline possibly storing the
result into temporary variables for keeping speed efficiecy.
2) the possibility of turning on and turnig off an instrument from
another instrument and/or to define its duration into the caller instr.
3) standard structured languages conditional flow of control statements:
if...elseif...else...endif,
switch...case...default..endswitch,
for...endfor,
while...wend,
do...while
(all operating at both i and k-rate)
4) semi-global variables, shared within several instances of the same
instr during the performance, but not within instrs of different number.
5) multi-dimensional tables and gen functions
6) multi-dimensional arrays which can be accessed from within an
expression:
;******EXAMPLE:
a1 = array[a2,a3] * 8 + koffset
obviously this will make tables redundant but they should be kept for
backward compatibility. Furthermore these arrays should be enabled for
both read and write operations.
7) more ideas......(from Csound community)
SCO language additions:
1) using symbolic constants as i and f p-fields
2) sending string values to the orchestra
3) macros containing a block of any number of notes of the same instr,
processed with arithmetic and logical operators by user calling
parameters
4) variables
5) functions and subroutines
6) arithmetic and logical operators
7) standard structured conditional and iterative statements
8) more ideas.....(from Csound community)
P.S. It would be very useful a documentation of data structure members
and functions used in Csound parser and engine. If anyone has explored
and learned them, is invited to share his knowledge with Csound
community. I will post my (very limited) part of comprehension in some
later message if you agree.
--
Gabriel Maldonado
mailto:g.maldonado@agora.stm.it
http://www.agora.stm.it/G.Maldonado/home2.htm
http://www.geocities.com/SiliconValley/Way/7041/home2.htm
|