> Thanks for the clarification. But it would still be the case, would it not,
> with an embedded version of the whole SAOL runtime, that you could create a
> reasonably efficient SAOL orchestra for any particular DSP block, and get
> samples into and out of it through the regular input/output facilities
> (realtime audio streams)?
>
> If that were the case, then sfront still could be used as a library of DSP
> code, but only on condition that it be possible to create multiple instances
> of the runtime, all running at the same time. I imagine such uses were not
> envisioned, but would they be possible or practical?
I'd have to look at it indepth to give an accurate answer, but intuitively
I'd answer it would definitely be possible/practical, but its probably not
the shortest path to getting a quality application up and running -- even
given the quantity of opcodes in SAOL, the work of rewriting them may be
less that the work of coaxing the sfront source code into producing the
runtime system that's needed in this application. I would say, that the
best bet is probably to write a filter program that takes the opcode
definitions in sfront/src/corecode.c and the wavetable definitions in
sfront/src/wtparse.c, and mechanically translate them from the string-based
macro language to actual C code, then finish the job by editing each
opcode by hand ...
--jl
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:50 EDT