| Richard Dobson wrote:
> 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, until now (alpha or beta version?), SAOL is very slow on PCs (at
least 10 times slower
than Csound).This makes realtime almost impossible.
> but would be a dramatic change to the nature of Csound - perhaps too
> much?
I think not so much.
> How far can it be taken before we end up reinventing CMIX?
What is the question about CMIX ? (excuse my ignorance). Is it better
than csound?
> > 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?
Yes, they can quite easily implemented as a transparent macro
preprocessor, so, for each call, a copy of code is generated.
> 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.
Yes, they are.
> So presumably they are not re-entrant. How
> would they behave if control occasionally jumped past them?
They will not operate well, because oscillators' phase is not
incremented all
times. Some restrictions which I think to be unavoidable, unless one
restart
writing Csound from zero using a different philosophy.
> 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),
these functions will be a particular case of intelligent macros. These
should generate more or less the following csound code:
;***anyfunc1
func anyfunc1(i1, i2, i3)
a4 oscili 1, i1,1
a5 oscili 1, i2,1
a6 oscili 1, i3,1
areturn a4+a5+a6
endfunc
:*** Caller instr
instr 1
iamp init 2000
if1 init 120
if2 init 220
if3 init 320
out (anyfunc1(100,200,300) + anyfunc1(i1,i2,i3) ) * iamp
endin
;------- code generated after the macro substitution
instr 1
iamp init 2000
if1 init 120
if2 init 220
if3 init 320
;***** start of first call substitution
a41 oscili 1,100,1 ;*** at each output variable name is postponed
a51 oscili 1, 200,1 ;*** a progressive number for each
;**** instance of func within the same instr
a61 oscili 1, 300, 1 ;*** to avoid conflicts
aret1 = a41+a51+a61
;****end of first call substitution
;**** start of second call substitution
a42 oscili 1,if1,1
a52 oscili 1, if2,1
a62 oscili 1, if3,1
aret2 = a42+a52+a62 ;**** the name of return variable is
;**** changed in respect of that of the first call
;**** end of second call substitution
out (aret1 + aret2)*iamp ;*** in this line the function calls are
;***substituted with the return values of the macros
endin
There could be some problems with the temporary output variable names,
which
should not disturb other names of the variables used in the caller
instr. So it is possible to merge the name of the function at each
variable name.
> 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).
Sorry, I don't understand. Why a modification of a k-rate argument could
be made at arate and what is its usefulness?
> > 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.
I agree. A limiting rule could be to use the same rate of the
conditional
value.
--
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
|