> Here is an orchestra that I made that makes it easy to
> turn your midi keyboard into a sample player.
Great ...
> 'doscil' doesn't correct pitch so that won't do.
You could change the sample rate using ftsetsr to do tuning
yourself, since doscil uses the sampling rate of the sample
to figure out how fast to play things out. However, since
ftsetsr is a k-rate function, that's not going to help you
doing things like faster modulations, although if you kick
the krate global parameter up high enough you might get
in the regime where it sounds smooth enough to use. Aside
from that, though, you're other alternative is to use
tableread() to write your own playback aopcodes -- since
tableread does interpolation, the hard part is done
already. Or if you want to do interpolation yourself, just
use integral arguments to tableread (at the moment, there's
an efficiency advantage in sfront to being explicit and
using int(a) in that tableread argument ...).
> //***** FIND BEST SAMPLE TO REPRESENT CURRENT PITCH *****//
> //***** IS THERE A CLEANER WAY TO DO THIS? **************//
Precompute a table at the start of program execution, of
size 128 (one for each midi note) that has points to the
best sample to use for each midi note. Then, just index
into the table to find the value of "which" using a
tableread command. You could make this an instr which
you execute from the SASL file, at time 0 -- the instr
would import the global table meant to hold to optimal
notes, as well as the tables, compute the map, then use
the turnoff statement to kill itself.
> and perhaps cut down on latency.
If by the latency you mean the time it takes for things
to start at the very beginning after running ./sa, that's
probably a lack of intelligent file reading on sfront's
part -- it's opening up and reading in each wav file at
the start ... there's a lot of room for improvement in
the way sfront handles large tables from a performance
standpoint ...
--jl
P.S. If you're thinking of making a general-purpose sort
of sampling engine, one thing you could do is to use
SASL table commands to specify the wave files. That way,
you could set things up so that a new sample set is just a
new SASL file, with the same SAOL file. If you assume you're
users are using a C-pre-processor, you can probably make
the interface even easier (note both SAOL and SASL files
get processed by the pre-processor if you use -gcc -cpp
options).
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:40 EST