In message <c=US%a=_%p=Studer_Prof._Aud%l=STUDERPROF/SPAAGEX1/00008F09@exchange
.spaag.ch> Matthias wrote:
>Hi ...
>
>On Friday, May 16, 1997 1:19 PM, Adam Lindsay wrote:
>> Oh, I know those opcodes well. (I know for my uses, 'reson' was the most
>> useful. Where did that one go?)
['bandpass' is likely to be similar to 'reson' in most implementations,
I think. Perhaps we should even standardize this.]
>The other application is, of course, audio synthesis (and composition?).
>>From my point of view, this has to include a framework for
>"to-be-defined" audio processing and controlling. For example, I would
>like to integrate a new SAFX box with some strange effects. For a
>content creator, there is no other way than to design the complete box
>except of the interfaces, which SOAL provides. The question is then, how
>do I implement such a box? Is a C-interface a resonable approach?
I'm not exactly sure what the question is here -- do you mean that
you would like to use a hardware effects processor (like a Lexicon
reverb or something) to implement the interface specified within SAOL?
This is certainly possible, but it seems like overkill to me; it
seems to me that most of the cost of an implementation is going
to have to be come from a good compiler/runtime package so that
the user-defined opcodes run efficiently.
Most content won't be able to take advantage of it, either, in the
scenarios I'm imagining, because my view is that "serious" content
will likely deliver its own effects code.
Much of my thinking about SAOL is centered on the idea that one
can build good compilers for it, for fast DSPs, with strong run-time
packages, so that the speed of a user-defined opcode written in
SAOL is "comparable" to the equivalent built-in opcode written
in a general-purpose language and linked in as part of the run-time
package. Does anyone have thoughts (pro/con) on the realism
of this goal?
>Or is the design of new functions and algorithms (in C)
>out of the scope that SAOL covers?
Yes, for the keyword "in C" -- it makes it impossible to deliver
platform-independent content for MPEG-4 if you need to rely on
an implementation having "special" non-standard built-in opcodes.
But I'm not sure what your take is on things that *must* be
implemented in C; the goal of SAOL is to make this largely
unnecessary.
I agree that there is still a hole in the MPEG-4 work when it
comes to the standardization of spatial effects processing,
which needs to continue to be addressed (I know that's your
particular interest, Matthias -- have you looked at the BIFS
in the Systems VM Core Experiments yet?) But besides
that, are there other areas where you think it's inadequate
to expect "to-be-defined" audio processing to be written
in SAOL?
Thanks for sharing your thoughts.
-- 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:11:08 EDT