Hello!
> http://arena.sci.univr.it/~bellomi/SAOL/
I've just read parts of their documentation. It is a good
project, although it doesn't solve all the problems concerning
CSound-to-SAOL conversion.
> Do you think the compatibility problems are matching up core
> opcodes from SAOL and CSound? Or is it differences in the
> basics of the two languages's semantics? I'm not actually
> very familiar with CSound ...
I think the major problem is the incompatibility of some
core opcodes. The Italian project mentions this problem in its
documentation:
"SAOL presenta un set di opcodes diverso da quello di
cSound. Alcuni opcodes di cSound non hanno un
equivalente in SAOL, mentre altri utilizzano una sintassi
o un insieme di argomenti diverso. Per cui il traduttore
deve associare ad ogni tipo di opcode di cSound un
algoritmo che lo converta in una sequenza di istruzioni
SAOL semanticamente equivalenti."
However, their converter doesn't solve this problem. Of
course, it's not an easy task, since there are many CSound
opcodes which doesn't have a corresponding SAOL opcode, e.g.
the CSound's "foscil" opcode (which I had to implement in the
"slingpng" orchestra and I cannot assure it's strictly correct).
There are also very complex opcodes, e.g. scanu/scans (for
scanned synthesis), pvoc/vpvoc (for phase vocoder), and many
others. Besides, without a detailed analysis, we cannot be sure
that some core opcodes are really implemented using the same
algorithm. For example, in instrument "five" of the "slingpng"
orchestra, I have converted the CSound's "tone" opcode into
SAOL's "lopass" opcode, but how can I be sure this was the
right decision? Maybe these two opcodes are implemented
using different algorithms.
> In general, though, if the hardest issues are core opcode
> matching issues, you might consider not using the SAOL
> core opcodes at all, and instead starting with the C code
> that implements the CSound opcodes, and translating them
> into SAOL. Sfront does a pretty good job of translating
> straightforward-looking SAOL back into C, and so the
> efficiency hit might not be that bad -- especially if you
> peek at the sa.c file along the way and reorganize the
> code accordingly.
I agree! It's a very good solution, although it's not a task
that can be quickly solved, considering the large amount of
CSound core opcodes. Moreover, CSound supports file I/O and
simple Graphic User Interface (e.g. CSound's "setctrl", "control",
"button", and "checkbox"), which the standardized SAOL does
not (as far as I know...). By the way, is the SAOL standard
"frozen" or is it possible to extend the language in the future?
> Listening to the two MP3s, the biggest difference seems to be
> the snare-drum timbre on the high end ...
Yes. This is instrument "three", one of most difficult
instruments to adjust. Even if the conversion of this instrument
seems straightforward, I wasn't able to make the SAOL
instrument sound the same as the CSound's one. Maybe the
problem is the conversion from CSound's "reson" into SAOL's
"bandpass", but I'm not sure.
Best regards,
Gustavo André Hoffmann
mailto:gusthoff@ieee.org
ICQ# 48696602
http://gusthoff.iuma.com
http://www.geocities.com/gusthoff
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:43 EST