> 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.
For filters, your best bet is to avoid the SAOL filters whose
transfer functions aren't normatively defined in the specification.
Basically, use these filter opcodes:
biquad(), allpass(), comb(), fir(), firt(), iir(), iirt(), port()
as described in standard and corrected in a few places in the
corrigenda -- see the last two appendices on this page:
http://www.cs.berkeley.edu/~lazzaro/sa/book/append/index.html
to download the PDF for those. Because the math for these
opcodes are normative, the exact math described in the standard
will be implemented for any compliant decoder, so you can use
them as you would SAOL code. Whereas the lopass() hipass()
bandpass() bandstop() filters don't have an exact normative
equation which they need to conform to -- instead, the
conformance document
http://lsiwww.epfl.ch/saog/forum/SA_conf.pdf
specifies filter behaviors in section 5.5, in terms of how
close the filter needs to be to a certain filter shape, which
isn't as exact (and actually, I haven't tested sfront against
this conformance yet so I don't know if it actually meets it).
> 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.
One way to proceed would be to collect statistics on the
publically-available CSound orchestras, to find a set of
core opcodes that would suffice for most orchestras. This
may be significantly smaller than the entire core opcode
set (I'm not really a CSound person, but I was under the
impression this was one of the goals of the Extended CSound
project, please correct me if this isn't right).
One nice part about recreating a library is that its a
parallizable project, if N people are interested each can
claim 1/Nth of the library and work independent on it ...
> 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...).
AudioBIFS handles the GUI in an abstract way, via the params[]
array, although I may be out of date on this. Another way of
abstractly handling files and GUIs is to attach SA_access_unit
streams to a running decoder to do that -- just like sfront
networking uses the SA_access_unit semantics to handle networking.
Both of these techniques have an aspect of being "outside the
standard", in that conventions need to be set of for just what
the params[] elements mean, and what it means to write one as
opposed to read one.
But how a running decoder should deal with a params[] read or
write or how it should process a new SA_access_unit is inside
the standard.
> By the way, is the SAOL standard
> "frozen" or is it possible to extend the language in the future?
MPEG has change control, it can add things to SAOL. Realistically,
this means joining MPEG and pushing your vision through the
organizational structure, or working with sympathic MPEG members.
Personally, I think the combination of
-- writing SAOL code
-- using the SA_access_unit and AudioBIFS interfaces to build
software that combines a compliant decoder with elements that
are "outside the standard" as described above
has a lot of power to it -- sfront networking went from a concept
to a working fielded system in 9 months, by using the SA_access_unit
interface to hook into the IETF multimedia standards (RTP, SIP, etc).
> Yes. This is instrument "three", one of most difficult
> instruments to adjust. [...]
> Maybe the
> problem is the conversion from CSound's "reson" into SAOL's
> "bandpass", but I'm not sure.
Yes, I'd try looking at the filter functions and coefficients for
reson, and reconstructing it using biquad() or maybe iir() or iirt(),
by creating a user-defined opcode. The calculation of coefficients
for biquad() can be done by i-rate or k-rate code in the user-defined
opcode, depending on the rate of change.
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:43 EST