Steven Curtin wrote:
> Hello-
> I have started to convert some of my Csound instruments over to SAOL
Great! I'd love to see and hear what you're doing as you work.
> and was wondering about how to do waveshaping. The "table" function does
> not have a corresponding "tablei" as Csound does.
Assuming you mean "tableread", it is interpolating. I don't
know why the spec doesn't say so, but I'll fix it in the next rev.
It should say: 'if x is not an integer, then the value shall be
interpolated from the nearby table values, as follows: (TBD)'.
It's already implemented this way in the code.
(Right now, all interpolation in 'saolc' is linear, so it sounds
pretty bad for non-oversampled wavetables. The spec on this
hasn't been written yet, but I'm hoping to get to it before
the next MPEG meeting and then bring the code up to spec.)
> Also the chebyshev
> polynomial table generator seems to be have been removed from the
> current
> spec, with just the polynomial generator left. Are we supposed to just
> use
> the polynomial and generate the cheby coeffients ourselves?
Yes. We had a discussion about 'mathematical opcodes' at the last
meeting and decided that things like cheby_poly and logbessel
weren't really necessary; they only contribute to opcode bloat.
Once you go down that path, there's a million things to think
about: gamma functions? Lagrange polynomials? etc, all of which
"could" be useful to some composer.
Chebyshev are particularly useful due to their relation with
FM synthesis, though, I guess. Maybe we should rethink that.
For the time being, it's easy enough to write an iopcode
that acts as a table generator (assuming you have the right
algorithm around).
The 'polynomial' ctg isn't done yet, but it's not hard to fix if you
look at the code. It will surely be in the next release.
> Also I have a very basic question- what is the root data type for
> signals,
> specifically in the saol compiler in Windows? I read somewhere in the
> document that only 16-bit integer is supported. Is floating point an
> option?
Eh? No, that's not right, can you give me a reference so I can
fix it. All calculation is done internally in double-float,
then converted to 16-bit integer for output. (The double-float
is nonconformant; it should check to make sure that it's 32-bit
on every machine. That's also in the next release). The
conversion to short is the last thing that happens before
output; signals on busses and so forth maintain double-precision.
(Also related to that, clipping doesn't happen until the
same time, following 5.3.3.3 bullet 10).
Best regards,
-- 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 : Mon Jan 28 2002 - 11:46:31 EST