| There is already a note on the Roland MKS-20. I run mine thru a
Alesis MIDIverb, which gives it the appropriate ringing overtone
exchange. It isn't perfect, but it's close enough to fool anyone
once it's recorded. Check out my 'Is it Real or Is It Roland Challenge'
in the MKS- note.
karl moeller
|
| According to Bob Moog in Byte magazine, SAS is a resynthesis technique
mostly involving additive sine wave synthesis, ala the Crumar GDS
(which I did some development work on at Bell Labs), Digital Keyboards
(also Crumar) Synergy, etc. Wendy Carlos is a big proponent of additive
synthesis. The new Kurzweil 150 is using a similar technology.
- Rick
|
| I read the Keyboard review of the MKS-20 last night, and it confirms
the notion that there's a sample for each note for each velocity
level. This is a staggering amount of information, even if the
samples are only a single cycle long. I put on my thinking cap
and figured out just how much storage was required for one cycle's
worth of 128 (MIDI notes) * 128 (velocity values) samples.
First some assumptions - assume the sampling rate is 40 KHz, and
the samples are 12 bits. Assume each sample uses only as much memory
as it must. 128 notes is 7 octaves, and each successive half step
up the scale requires 1/(12th root of 2) as much storage as the
previous. We could do this as an enormous power series, i.e.,
1 + 1/(2^(1/12)) + 1/((2^(1/12))^2) + 1/((2^(1/12))^3) + ...
+ 1/((2^(1/12))^127)
As this was a "back of the envelope" calculation, my Amiga was busy
plotting yet another detail of the Mandelbrot set, and I couldn't
find a closed form for such a series, I resorted to some simplifying
approximations.
First, each octave takes up half as much space as the next lower
octave. This reduces it to a problem of evaluating that series
only to the 1/((2^(1/12))^11) term. The whole set then takes
1 + 1/2 + 1/4 + 1/8 + 1/16 + 1/32 + 1/64
times the storage for the first octave. Well, this is easy - that's
just a factor of 2 (actually, 2 - 1/64, but between friends, what's
1/64?). Now how do we get the storage for one octave? Now we get
sweeping - a reasonable first approximation is that the *average*
sample length in the first octave is somewhere between 1 and 1/2
times the lowest note's sample length. Pick 3/4 as a conservative
average value. 12 * 3/4 = 9, so say the first octave takes (less
than) 9 times as much storage as the first note. All 7 octaves take
(less than) twice that, so the whole sample set FOR ONE VELOCITY
VALUE takes 18 times as much storage as the lowest note does.
So how much storage does the lowest note take? MIDI note 0 is the
16 cycle C (it's not exactly 16 Hz, but that's close enough). At
16 Hz one cycle sampled at 40KHz requires 40K/16 samples, or 2500
samples of 12 bits each. That's 3750 bytes.
So, that comes to 18 * 3750 or 67500 bytes per velocity value.
If there really is a sample set per velocity value, we need 128
* 67500, or 8640000 bytes. Now, 8 megabytes is an awful lot
of storage, even if it is ROM, to cram into a $1500 2 high rack
mount box. And even if there were that much ROM, you still need
to do a lot of processing to make it sound good - a piano most
assuredly does not owe its magnificent sound to a single waveform
repeated throughout a note's life.
What this all says to me is unless/until Roland spells out exactly what
SAS is, we (and the magazine editors) are just waving our hands.
len (who isn't that good at arithmetic, so check my work)
|
| Nice work Len.
No way there are 128 samples per note. No way. The Kurzweil can't
even do that.
I don't think SAS has anything to do with "sampling". My reason
for saying this is their line of Juno synthesizers sport this
same technology. As far as I know, the Junos allow the user
to create custom sounds (like the DX series) which couldn't occur
if the technology were based on samples (unless it were like the
DW series from Korg, which I doubt).
What we need is to sneak a peak at a Juno manual. Are you gonna
be going down to EU's any time soon Len?
Todd.
|