>(d)Oh, I hadn't realised this wasn't happening. I guess I'll have to do
some
>more research as to what saol constructs can't be block processed, is
>feedback the only limiting factor?
Yes, I think so. It is possible to statically detect these sorts
of constructs, I think. At least, I think the rule "the instrument
is safe if no variable is read before it is written" should be
conservative enough, if expanded to include a-read tableread()/
tablewrite() pairs and maybe some of the opcodes. You could
get very fancy with statically detecting feedback structures and
turning them into block-by-block versions using special-case rules.
There's a good literature on compilers for parallel architectures that
could be leveraged towards this problem, I think.
>Is the event scheduling granularity in saol sample accurate, or is it
>limited to the krate like csound?
The latter. As are changes to global variables and tables, and any
other sort of inter-instrument communication.
>Would you be for/against the mainline saolc codebase heading in that
>direction? It seems that because the spec is set in stone (more or less),
>saolc could be a suitable target for iterative refinement and
optimisation -
>a large amount of energy could be directed at making it more and more
>efficient without having to worry about source code compatibility issues.
Yes, I'm definitely in favor of this! I'm quite happy to see others improve
saolc, and I can host the changes and a "most recent" version on the
MIT site as well if needed. The current version (fortunately or not :)
will live on, because it's the official reference software. Since saolc
is 99% compliant with the spec, all that is really needed is efficiency
improvements, user interfaces, and so forth, not major comparison to
the spec. (Although there are some known bugs and areas of non-compliance).
We're not actively working on saolc here anymore, so I'm delighted to
see others pick it up.
saolc is in the public domain, so it could be used as the basis for
a proprietary implementation, too--changes don't necessarily have to
be released back to the world (although of course I'm happy to see that
happen.)
There's an extensive (40-pp.) technical report on the internal operations
of saolc, for those who want to understand it deeply, on my personal
web page under "papers".
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:34 EDT