> A question about the rate of ftlen, ftloop, ftend (5.9.6.1- 5.9.6.3). [...]
A few comments here:
[1] The "state-readout" table opcodes (ftlen, ftloop, ftloopend, ftsr,
and ftbasecps) shouldn't affect the optimizations, since they aren't
changing state.
[2] The analogous "state-changing" table opcodes (ftsetloop, ftsetend,
ftsetbase, ftsetsr) are all defined as kopcodes.
[3] Here's the data structure sfront uses for a table:
[in the sa.c code produced]
typedef struct tableinfo {
int len; /* length of table */
float lenf; /* length of table, as a float */
int start; /* loop start position */
int end; /* loop end position */
float sr; /* table sampling rate */
float base; /* table base frequency */
/* precomputed constants */
int tend; /* len -1 if end==0 */
float m; /* start/len */
float n; /* end/len, if end=0 1-(1/len) */
float dmult; /* sr*atime */
float lmult; /* (sr*atime)/basefreq */
float diff; /* n - m */
float *t; /* pointer to table entries */
float stamp; /* timestamp on table contents */
} tableinfo;
Note the section of "precomputed constants" -- these are constants
that the various a-rate table opcodes (loscil, doscil, oscil, ect)
need to go fast. The ftsetloop, ftsetend, ftsetbase, ftsetsr opcodes
recompute these constants as needed to reflect the changes -- I
found this was the sensible way to make the a-rate opcodes go fast.
Also note stamp -- this is used to make the semantics of the SASL
table command work right (5.11.6 NOTE).
Finally (as Bertrand Petit has pointed out to me in emails) the
place where sfront really falls down in the table department today
is for mastering applications -- a natural use for SAOL is to load
in a bunch of individual tracks using table pairs (left/right channels)
and the sample wavetable generator, and then write a SAOL instr that
does fades, leaves blank space, ect. Sfront does this really horribly
right now -- it doesn't expect to see 100MByte tables that will only
be played once, and that need to be streamed into memory ...
--jl
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:53 EST