> is legal saol syntax and results in two separate instances of flanger being
> created (one for each channel) or whether opcode signal parameters are
> always single valued.
All of the signal and return parameters for core opcodes are scalars, so
the syntax:
...
asig stereoIn[2],stereoOut[2];
...
stereoOut = flange( stereoIn );
...
is in fact not legal. This includes the simple math opcodes as well, so
stereoOut = sqrt( stereoIn );
is also not legal, and needs to be written as
stereoOut[0] = sqrt( stereoIn[0] );
stereoOut[1] = sqrt( stereoIn[1] );
The story is more complex for user-defined opcodes -- as explained in:
http://www.cs.berkeley.edu/~lazzaro/sa/book/opcodes/user/index.html#header
parameters to user-defined opcodes can be arrays:
kopcode foo (ksig a[3], ksig b[inchannels], ksig c[outchannels])
{
ksig d[4], e[inchannels], f[outchannels];
return(d);
}
An opcode call to foo may provide arguments of width 1 for all
three parameters, or alternatively:
-- first argument of width 3
-- second argument has the width of the input port of the
calling instrument
-- third argument has the width of the output_bus of the SAOL
orchestra
Opcode foo declares several arrays as variables well, while
the meaning of inchannels is the same as for parameters, the
meaning of outchannels is different -- it indicates the width
of the calling instrument, not of the output_bus.
Finally, in this example, the return width of the opcode is 4.
One could write user-defined opcodes that implement quasi
width-polymorphic versions of the core opcodes, by using the
inchannels and outchannels feature.
Another observation: an "extended" version of MP4-SA that gave
the core opcodes width-polymorphism could be mechanically
translated into compliant MP4-SA pretty easily for transmission
to compliant MP4-SA decoders, via simple replication (with lots
of tricky code for the edge cases, like opcode calls in
expressions that have ordering restrictions, like (foo(a) && bar(b))
where foo and bar have side effects).
I believe this is all accurate, but since I wrote it by referring
to the book instead of the standard, there may be book bugs
unmasked by this email :-)
--jl
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:35 EST