Michael Gogins wrote:
>I don't think user-defined opcode macros are really up to this (but correct
>me if I'm wrong; if the language is expressive enough and the compilers are
>good enough, then I am wrong). I don't care about SAOL bitstreams ALWAYS
>being playable by EVERY decoder as long as the plugins can be found
>somewhere (see Buzz).
I claim that the user-defined opcode really is up to this. There's
only two things I can think of that you might want to do that you
can't:
1. UDO's can't be recursive or mutually-recursive.
2. You can't write downsampling UDO's that take a-rate parameters
and return control signals.
1. can be worked around with a variety of programming tricks (maintaining
a stack of states yourself). 2. can be worked around by making your
UDO return an asig and immediately using the downsamp() core opcode
on the result.
Is there a reason you think of the UDO system in SAOL as impoverished?
I note that the implementation I used in 'saolc' (UDOs as macros) is
not required, and in fact requires a lot of work to get right. Thinking
of UDOs as macros makes me think of CPP macros, which is the wrong
model. UDOs have much richer properties: They are statically scoped
and can declare variables that do not interfere with those in their
called. They can return multiple values. They can maintain their
own state (in an object-oriented style). They can be used in opcode
arrays just like built-ins.
They will never be as fast as the built-ins, just like a C compiler
can't write code for C functions that would be as fast as a well-tuned
stdlib implementation. But they will be close on some platforms,
and IMHO the cross-platform advantages make up for that.
Best,
-- Eric
+-----------------+
| Eric Scheirer |A-7b5 D7b9|G-7 C7|Cb C-7b5 F7#9|Bb |B-7 E7|
|eds@media.mit.edu| < http://sound.media.mit.edu/~eds >
| 617 253 0112 |A A/G# F#-7 F#-/E|Eb-7b5 D7b5|Db|C7b5 B7b5|Bb|
+-----------------+
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:24 EDT