The Eat at Joe's Kawai K5000 Message Board Digest
Converting Rates to Time Values
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
Re: Rate/Time Formula
Tuesday, 24-Mar-98 08:44:07
130.67.65.6 writes:
First of all, you said something about sending a letter to Kawai. I hope that will
solve the matter.
As already stated, level adjustment is an accelerated type of motion, and the
acceleration is greater for low levels than for high ones. The general solution
should therefore be some sine or exponential function, depending. Just what that
formula is and how to fit it to the constants in our case eludes me at present,
but I might succeed if I keep working on it.
In any case, the simplest solution may be to use a table derived from systematic
experiments. I will probably make such a table for my own uses as soon as I
have a satisfactory FFT for harmonic analysis, in which case I will publish the
table here.
As noted by several posters here, the SoundDiver import routine does not work
satisfactorily, and the reason might be that they have used some simplistic
and/or erroneous formula for the Rate/Time/Level relationships. Kawai should
realize that this is bad publicity and help us get it right.
Tore
tl001@online.no
------------------------------------------------------------------------------------------
Re: Re: Rate/Time Formula
Tuesday, 24-Mar-98 13:18:11
192.86.155.91 writes:
Wouldn't a table be a problem since the rate seems to be dependant not only on
the relative values between the beginning and end points, but also the
absolute values? It seems like you would need either a three dimensional table,
or a large and cumbersome set of tables.
*QUOTE FROM TORE*
One thing that is certain about the time needed to change a level is that this
movement is accelerated. And it appears that the acceleration is greater for low
levels than for higher ones. Going from level 0 to 10 in the Harmonics Envelopes
takes around 10 secs at a rate of 42, going from 50 to 60 takes 16 secs.
*UNQUOTE*
-Kenji
------------------------------------------------------------------------------------------
Re: Re: Re: Rate/Time Formula
Tuesday, 24-Mar-98 17:52:39
130.67.65.101 writes:
QUOTE
It seems like you would need either a three dimensional table, or a large and
cumbersome set of tables.
UNQUOTE
Yes, in some cases one would need a 3-D table, and it would be a real hassle if
we had to do it by hand. However, you talk about a computer
program, and that simplifies matters.
When we have to compute times from start level, end level and rate, a 2-D table
would be enough, it seems. Let us call the matrix D() for Delay in order to let
T mean the physical time. Supposing that the table of delays has been recorded
at a rate of 40, we would have:
T = D(L1, L2) * 2^(-R/8) * 32
L1 is the start level, L2 the end level, R is the rate, 32 is 2^(40/8). Actually,
the times thus obtained are not 100% linear if you use VERY
slow rates. I hope they are linear with the fast rates that are normally used.
For finding the start or end level, one would have to search the matrix D(). This
is clumsy, but no match for a computer - and it's the only
option unless we find a formula.
Another thing, Kenji. Could you find if there is a way to make tabs or blank
spaces in this font? Spaces and tabs are both ignored, so it's hard to make tidy
arrangements of time tables, etc.
Tore
tl001@online.no
------------------------------------------------------------------------------------------
The Formula - or very nearly so...
Friday, 27-Mar-98 14:42:24
130.67.0.147 writes:
I have made a formula that relates the levels, the rates and the time it takes to
effect changes in level. This formula applies to Level and Rate in the Harmonics
Envelopes page. The key element is a factor that I call Delay which is defined as
follows:
D = (ln(LH - LL) - (80 - LL) * 0.1 + 13.4)
LH is here the higher of the two levels, LL the lower. This formula is derived from
an exponential function of the simplest type, namely Ce^(kt). In fact, this
function may be a bit too simplistic, but it seems to be good enough for our
purposes.
Level adjustments are accelerated, and the acceleration seems to be inversely
proportional to the level. The solution of the corresponding differential equation
gives us the exponential function mentioned above. The formula for D says that
zero acceleration occurs at Level 80 - which is beyond the maximum value of
63. Thus the acceleration does not begin at 0 when the adjustment starts, even
if we start at 63, which is one reason why I fumbled a good deal before I found
a workable formula. The number 80 is not necessarily correct, and the same holds
for the other constants, but they appear to be close to the real values.
The time it takes to effect a level change is proportional to 2^(-Rate/8) and to
Delay. The Time in seconds can therefore be computed as:
T = 46 * D * 2^(-R/8)
where 46 is a proportionality factor. In most situtations, as I see it, what we
shall want to know is the Rate, since this is a purely internal parameter. The Rate
is given as:
R = 8 * log2(46 * D / T)
And if we need to adjust a level while keeping the time constant, we shall have to
compute the new rate R2 from the old one R1 as follows:
R2 = R1 + 8 * log2(D2 / D1)
where D2 and D1 are the new and old D, respectively. Such calculations are hardly
practicable unless you use a computer or programmable calculator.
If we calculate LL - the lower level - we shall get the exponential function that
I departed from in making the formula for D. Calculating LH is worse. We get
an equation of the type ln a + a = constant, which may have to be solved by some
sort of approximation. If you know a better way, I would like to hear about
that.
As noted before by Jens (I think), two consecutive levels will lead to one stage
being skipped, no matter what the rate is. For keeping the amplitude "level"
across two stages one therefore has to let the levels differ. This is one case
where the formulas above may prove very helpful in deciding how to set the rate in
order to obtain a specific delay.
*
When I test these formulas, I find that they are not quite exact, although they
are reasonably close most of the time. I hope that you will test them too and
suggest improvements.
Tore
tl001@online.no
------------------------------------------------------------------------------------------
Re: The Formula - or very nearly so...
Monday, 30-Mar-98 04:52:34
130.67.2.140 writes:
For some reason I left a proportionality factor of 46 in these formulas. We should
of course bake it into the Delay expression as follows:
D = (ln(LH - LL) - (80 - LL) * 0.1 + 13.4) * 46
It is possible to arrange this formula with fewer terms, but I don't think
readibility is enhanced that way.
We then get the Time in seconds as:
T = D * 2^(-R / 8)
And the Rate as:
R = 8 * log2(D / T)
*
I forgot to say that these formulas are not exact for extremely slow rates. Such
rates are largely uninteresting for musical purposes, so this is no big deal. The
question is whether they hold for very short time intervals of the sort that occur
in onset transients. I have looked for ways to test this, using beats etc., but I
have not yet found a workable scheme. Maybe someone else has ideas here?
*
And I said that the acceleration is inversely proportional to the level. It is of
course proportional to (80 - Level), which is something else.
Tore
tl001@online.no
------------------------------------------------------------------------------------------
Re: Re: The Formula - or very nearly so...
Monday, 30-Mar-98 10:38:39
194.172.230.108 writes:
Hi Tore, hi all!
When I programmed my 'ADDpeggio' patch, I used the envelope loop function, the
built-in echo effect and my ears to find multiples of a given delay time.
You can hear quite well whether a looped attack coincides with its echo or they
drift apart. This is how I found the regularities that we might call the 'constant
levels formula': "Reducing the rate by 8 means doubling the time".
I observed as well some time quantization effects: Using envelope loops, I found
a maximum loop frequency of about 43.5 Hertz. This gives 11.5 milliseconds
as shortest possible time unit. We should possibly take time quantization into
account when the times are very short. I expect a sort of 'level change
quantization', too. This should have effects on very long times and very small
level differences and may also have to do with the 'no flat' rule (for all stages
except the sustain).
How did you measure the times in order to develop your formula, Tore? And what
do you mean by 'acceleration'? The nonlinearity in the delay/level relation
that you measured, or did you really observe a curved level slope? Could it perhaps
be explained with a linear slope on an amplitude scale (which is
non-logarithmic)?...
I would like to have a model of the envelope algorithm rather than a formula.
What about a kind of 'increment and compare' algorithm?
Or, couldn't we make the MORF calculator do the work for us?
Or Kawai? ;-)
So many questions...
Jens Groh
------------------------------------------------------------------------------------------
Re: Re: Re: The Formula - or very nearly so...
Monday, 30-Mar-98 14:10:04
130.67.66.152 writes:
Hi Jens -
QUOTE When I programmed my 'ADDpeggio' patch, I used the envelope loop function,
the built-in echo effect and my ears to find multiples of a given delay
time. You can hear quite well whether a looped attack coincides with its echo or
they drift apart. UNQUOTE
Thanks, I'll try that.
QUOTE How did you measure the times in order to develop your formula, Tore? UNQUOTE
I just measured it with my wrist watch. Changing levels at rate 40, times range
from about 6 secs to 22 secs.
QUOTE And what do you mean by 'acceleration'? UNQUOTE
I mean level change per second per second. Going downward from level 60 at rate 40,
it takes 16 secs to reach level 59, 20 secs to reach 50, 21.5 secs to
reach levels 30-10. Hence, the speed - level change per second - is increasing
during this movement.
QUOTE Could it perhaps be explained with a linear slope on an amplitude scale
(which is non-logarithmic)?... UNQUOTE
I guess you mean to say that if we have an expression of the type log(exp(Amp)),
this reduces to Amp or maybe Amp times a constant. I hoped for the same
thing, but it looks like we have log(log(Amp)) or, conversely, exp(exp(Level)),
unfortunately.
QUOTE I would like to have a model of the envelope algorithm rather than a
formula. What about a kind of 'increment and compare' algorithm? UNQUOTE
I am not sure what you mean by an "increment and compare" algorithm. When we move
from a high level to a low level, we can express the level as a function
of the time as follows:
s LL = LH - exp(T * 2^(R / 8) / 46 + (80 - LH) * 0.1 - 13.4)
which is a "normal" exponential function. I guess this is what you mean by an
"envelope algorithm". Going from a low level to a higher one, however, is worse.
We ought to get a function of the type (1 - cos kt), since the acceleration now
decrease with increasing level, but I have not been able to find it yet. Anyway,
the time it takes to change a level appears to be the same whether we go upward
or downward. Maybe some of you math gurus can use that bit of
information to find a solution?
QUOTE
Or, couldn't we make the MORF calculator do the work for us?
Or Kawai? ;-)
So many questions...
UNQUOTE
Yes, I am also trying to find better approaches. We'll see...
Tore
tl001@online.no
------------------------------------------------------------------------------------------
Re: Re: Re: Re: The Formula - or very nearly so...
Tuesday, 31-Mar-98 06:46:34
194.172.230.108 writes:
Hi, Tore! (Other contributors very welcome, too!)
You wrote: QUOTE
I guess you mean to say that if we have an expression of the type log(exp(Amp)),
this reduces to Amp or maybe Amp times a constant. I hoped for the same thing,
but it looks like we have log(log(Amp)) or, conversely, exp(exp(Level)),
unfortunately.
[...]
I am not sure what you mean by an "increment and compare" algorithm.
UNQUOTE
I understand 'amplitude' as the peak value of a wave, and 'level' as its logarithm.
In the K5000 envelope settings, we have levels. But somewhere inside the
synthesis process, they must be transformed into the amplitude factor that the
sine wave is to be multiplied with. This exponent function can be realized with a
look-up table. Keep in mind that the K5000 must calculate up to 2048 envelopes
(32 sources * 64 harmonics) at the same time! Thus, the algorithm that
generates the envelopes must be very, very simple. A possible solution to generate
an envelope slope would be the following: Increment (or decrement) either
the current level or the current amplitude by a constant value and repeat this
step in intervals of, say, 11.5 milliseconds. The increment/decrement value can be
taken from a look-up table, again. Now, if they took the amplitude and not the
level, an acceleration of a falling slope can be explained: Equal amplitude
steps become increasing level steps. Conversely, for a rising slope with constant
amplitude increments you get a retardation on the level scale. The slope
ends when the target amplitude (or level) is reached - that's the 'compare' part.
In the special case that the levels are equal, the increment value is zero. Then,
the algorithm can only take either no time or infinite time, depending on how the
comparison is done. The programmers decided for 'no time', of course. That
explains the 'no flat' restriction.
Do you think you can fit your measured times to that model, Tore?
Jens Groh
------------------------------------------------------------------------------------------
Re: Re: Re: Re: Re: The Formula - or very nearly so...
Tuesday, 31-Mar-98 15:14:45
130.67.2.100 writes:
Jens wrote:
Keep in mind that the K5000 must calculate up to 2048 envelopes (32 sources * 64
harmonics) at the same time! Thus, the algorithm that generates
the envelopes must be very, very simple.
This is where I wonder: is it really done digitally? The formula that fits the data
looks like a typical analog event, with its exponential rise and decay.
Though, it would be very strange if an analog signal appears before the DCF/DCA,
so I suppose it is really digital, but it certainly looks analog from the
formula.
Equal amplitude steps become increasing level steps. Conversely, for a rising
slope with constant amplitude increments you get a retardation on the
level scale.
Yes, that is right, but I am afraid you have missed the point. There is no
retardation. The level adjustment is always accelerated, even if the acceleration
is less in the higher levels. This means that if we go from level 0 to 60, the
derivative of the acceleration is negative, but the acceleration itself remains
positive.
I am sorry to demolish the scheme you put forward, because it would have been much
simpler, but it just does not fit the data.
I have tried to figure out how an exponential function could be broken down into
some sort of "increment and compare" algorithm, but I don't see any simple
way of doing it so far.
*
About data and fitting, let's see how my formulas fit. If we go from Level 0
upward at Rate 40 and take down pairs of (Level, Time) we shall get something
like this:
(1, 7.5), (2, 9), (5, 11), (10, 12), (20, 14), (30, 16), etc.
Applying the formulas instead gives us these pairs:
(1, 7.9), (2, 9.0), (5, 10.8), (10, 12.5), (20, 14.9), (30, 17.0), etc.
The fit is fairly good, and it gets better for faster rates. My conclusion is that
we have an exponential function, but I don't know how to program it in a fast and
digital way.
Tore
tl001@online.no
------------------------------------------------------------------------------------------
Re: Re: Re: Re: Re: Re: The Formula - or very nearly so...
Wednesday, 01-Apr-98 03:38:06
194.172.230.108 writes:
Tore wrote:
I am sorry to demolish the scheme you put forward, because it would have been much
simpler, but it just does not fit the data.
What a pity!
...was my first thought. But then I noticed a slight difference between how you
measured falling slopes and rising slopes. For falling slopes, you varied the
smaller level, for rising slopes, you varied the greater one. That's not wrong.
But, what if only the greater level determined the amplitude increment value?
Then, you would have measured falling slopes with equal decrements, but rising
slopes with different increments. This could lead to the impression that there is
an acceleration there, too.
Could this be our last hope for a simple explanation?
Jens Groh
------------------------------------------------------------------------------------------
Re * 7: The Formula - or very nearly so...
Wednesday, 01-Apr-98 06:22:58
130.67.65.182 writes:
QUOTE For falling slopes, you varied the smaller level, for rising slopes,
you varied the greater one. UNQUOTE
I am not quite sure what you mean here.
In any case, I think Jens may have a good point when he talks about whole-number
algorithms that must be fast. There are several ways that the behavior of
such algorithms could resemble acceleration.
What I wonder about is the actual format of the signal as it leaves the "oscillator"
(i.e. DHL/DHE). Is it comparable to a sampled waveform, or is it in some
other format that is converted to actual waves after the DCF/DCA? It is very
difficult to think about these matters without knowing more about those details.
Let's hope that the reply to Kenji's letter will bring us some answers.
Tore
tl001@online.no
------------------------------------------------------------------------------------------
Re * 8: The Formula - or very nearly so...
Thursday, 02-Apr-98 05:58:23
194.172.230.108 writes:
Hi Tore!
You are not sure what I mean? Well, perhaps I should have said 'lower' and
'higher' level - sorry if my bad English was the reason.
I assume that the increment value (resp. the amplitude gradient) is a function of
the higher level and the rate only, but not a function of the lower level. And I
assume that the slopes are amplitude-linear, not level-linear.
Well - it's only a hypothesis. Let me try to sketch a few formulae:
start_ampl = 2^(start_level/8)
end_ampl = 2^(end_level/8)
ampl_gradient = incr_val / time_unit
higher_level = max(start_level,end_level)
lower_level = min(start_level,end_level)
My hypothesis:
time_diff = (end_ampl - start_ampl) / ampl_gradient
abs(ampl_gradient) = some_factor * 2^(rate/8) * 2^(higher_level/8)
For a rising slope follows:
higher_level = end_level
lower_level = start_level
ampl_gradient = some_factor * 2^(rate/8) * 2^(end_level/8)
=> time_diff = (2^(end_level/8) - 2^(start_level/8)) /
(some_factor * 2^(rate/8) * 2^(end_level/8))
For a falling slope follows:
higher_level = start_level
lower_level = end_level
ampl_gradient = -some_factor * 2^(rate/8) * 2^(start_level/8)
=> time_diff = (2^(end_level/8) - 2^(start_level/8)) /
(-some_factor * 2^(rate/8) * 2^(start_level/8))
Wow - this IS a time/rate formula! I didn't realize that before I wrote it down
(and made some refinements).
Theoretically, it should be sufficient to make one exact measurement to determine
the unknown 'some_factor'. I think you have a lot of data, Tore, which the
formula can be verified with. But I'd like to test it myself, too.
Two things are for sure: The 'constant levels rule' applies for the formula, and
a rising slope takes the same time as a falling slope with the same levels and rate.
Is this what we were looking for??? If yes, I hope we'll make really cool sounds
of it!
Jens Groh
------------------------------------------------------------------------------------------
Re * 9: The Formula - or very nearly so...
Thursday, 02-Apr-98 09:17:35
130.67.65.197 writes:
Thanks for your ideas. I have to mull them over for a while. Just want to say that
I have tried to use your ideas about the need for a fast algorithm to make a
model that looks very promising. It can be implemented with three 32-bit registers
where you do some adding and shifting. The resulting ramp is neither
amplitude-linear nor level-linear, but it fits the data almost EXACTLY. It is
probably too good to be true, so I will check it carefully before I publish it...
Tore
tl001@online.no
------------------------------------------------------------------------------------------
An answer
Monday, 06-Apr-98 03:39:34
194.172.230.108 writes:
After having made my own measurements, I have to tell the readers that the answer
to my 'big question' is: "No." Although the formula had some promising
properties, it produces values that do not reflect what the K5000 does. Well,
in science, even such a negative answer is considered useful. This may serve as
a consolation for all who may be disappointed now, me included.
Jens Groh
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
An Increment and Compare Algorithm
Saturday, 04-Apr-98 07:58:26
130.67.1.248 writes:
I have been trying to use Jens' idea about an increment and compare algorithm
to devise a program that fits the data rather well. Consider this correspondence
between end levels and the time it takes to reach them when we start from level 0:
Start level 0, end level: 10 20 30 40 50 60
Times at rate 40 in secs: 11.9 14.2 16.0 17.7 19.3 20.9
Increments : 2.3 1.8 1.7 1.6 1.6
In other words, we have a function that tends toward an arithmetic progression in
the higher levels. If what is actually increased is the amplitude, as suggested
by Jens, the amplitude will have to to increase geometrically in order to give the
arithmetic progression above. So I thought, what if we make a function that is
starts out as an arithmetic progression and ends as a geometric one? This could be
done by means of a 32-bit register that is shifted 8-bits and then added to
itself. We could emulate that in C as follows:
sum = 256;
time = 0;
while (amp < end_amp)
{
sum += sum / 256;
amp += sum;
time++;
}
This loop is supposed to be executed at equal time intervals. Now, if sum is an
integer, division by 256 will yield 1 as long as 256 <= sum < 512. Hence, we
will have an arithmetic progression. When sum gets large, however, adding 1 / 256
of its value will be almost equivalent to multiplying by (1 + 1 / 256), and
we will have a geometric progression.
I have made a C program that does these calculations (attached below). Running it
produces this set of values at rate 40:
0 10 20 30 40 50 60 From/To
0.0 11.9 14.2 16.0 17.7 19.3 20.9 0
11.9 0.0 13.5 15.8 17.6 19.2 20.9 10
14.2 13.5 0.0 15.1 17.4 19.2 20.8 20
16.0 15.8 15.1 0.0 16.7 18.9 20.8 30
17.7 17.6 17.4 16.7 0.0 18.3 20.5 40
19.3 19.2 19.2 18.9 18.3 0.0 19.9 50
20.9 20.9 20.8 20.8 20.5 19.9 0.0 60
This fits the observed values very well. Modifying the parameters a bit we can get
this set of values:
0 1 2 3 4 5 From/To
0.0 6.9 8.3 9.1 9.7 10.2 0
6.9 0.0 7.0 8.4 9.3 9.9 1
8.3 7.0 0.0 7.2 8.6 9.4 2
9.1 8.4 7.2 0.0 7.4 8.7 3
9.7 9.3 8.6 7.4 0.0 7.5 4
10.2 9.9 9.4 8.7 7.5 0.0 5
Or this one:
55 56 57 58 59 60 From/To
0.0 15.7 17.0 17.9 18.5 19.0 55
15.7 0.0 15.8 17.2 18.0 18.6 56
17.0 15.8 0.0 16.0 17.4 18.2 57
17.9 17.2 16.0 0.0 16.2 17.5 58
18.5 18.0 17.4 16.2 0.0 16.3 59
19.0 18.6 18.2 17.5 16.3 0.0 60
The match is not perfect, but it is very close. At least, this is a purely digital
and very fast way to obtain those values that looked to me like an exponential or
logarithmic function (which also fits the data rather well).
The deep question is why Kawai should want to do it this way. They could simply
have added or subtracted 1 / 256 of the amplitude to the amplitude itself
rather than using the auxiliary sum variable. And this procedure would have given
us the level as a linear function of the time. However, that algorithm does not
fit the data, so they did not do it that way, for whatever reason.
What is not explained by this program is the behavior of the rates, but this could
be implemented in a number of ways. We agree that the time is proportional
to 2^(-Rate / 8), but it looks like this formula is not quite exact - raising the
rate by 8 makes the time drop to slightly less than one half, it seems, and that
makes me wonder how it is actually done.
Finally, here is the program:
#include
#include
#define MAXAMP 0xffffffffL
void main(void)
{
unsigned long sum, time, amp, end_amp;
float level, end_level;
for (level = 0; level <= 60; level += 10)
printf("%5.0f ", level);
printf("From/To\n\n");
for (end_level = 0; end_level <= 60; end_level += 10)
{
for (level = 0; level <= 60; level += 10)
{
amp = MAXAMP * pow(2, (level - 63) / 8);
end_amp = MAXAMP * pow(2, (end_level - 63) / 8);
sum = 256;
time = 0;
if (amp < end_amp)
while (amp < end_amp)
{
sum += sum / 256;
amp += sum;
time++;
}
else
while (amp > end_amp)
{
sum += sum / 256;
amp -= sum;
time++;
}
printf("%5.1f ", time / 140.0);
}
printf(" %2.0f\n", end_level);
}
}
Tore
tl001@online.no
------------------------------------------------------------------------------------------
Re: An Increment and Compare Algorithm
Saturday, 04-Apr-98 08:02:01
130.67.1.248 writes:
Well, the PRE tag kept the tables tidy, but the board still removed the empty
lines. The intelligent reader will understand that the #include files in the C
program are STDIO.H and MATH.H - which disappeared because they were written
within angle brackets.
Tore
tl001@online.no
------------------------------------------------------------------------------------------
Re: An Increment and Compare Algorithm
Monday, 06-Apr-98 15:11:35
192.86.155.91 writes:
That is some excellent work you've done. How would one calculate values for rates
other than 40 using this formula. I would help out more myself, but my
K5000 is *STILL BEING REPAIRED* so I can't test anything out!
!!@#&@!?$#*
Can you believe Kawai shipped the replacement parts that were under warranty to
the authorized repair center COD??? They are supposed to *pay* the
repair center for labor, not charge them for parts!
Anyway, is it a matter of changing the constant in this line???
printf("%5.1f ", time / 140.0);
Or is it more tricky than that?
I'll put your algorithm into a little rate calculator applet for everyone to use.
I guess I just need this last little thing though.
-Kenji
------------------------------------------------------------------------------------------
Re: Re: An Increment and Compare Algorithm
Monday, 06-Apr-98 17:57:26
130.67.65.114 writes:
QUOTE
How would one calculate values for rates other than 40 using this formula.
UNQUOTE
The time is proportional to 2^(-rate/8), so you in order to get the time for
other rates than 40 you have to divide the time by 2^(-40/8), i.e. 1/32, and then you
multiply with the new factor, which would be something like pow(2, -rate/8) in C.
QUOTE
I'll put your algorithm into a little rate calculator applet for everyone to use.
I guess I just need this last little thing though.
UNQUOTE
Well, I don't think it is quite exact, but it is probably good enough. For that
matter, so is this formula:
time = log(level - end_level) + level * 0.1 + 5.4) * 46 * pow(2, - rate/8.0;
If I trim this formula a bit, the results get very close to the tables as published.
I think we can still get better approximations, especially if we get some help
from Kawai. What I would like to know is why they chose to use such a nonlinear
function for the envelope.
Tore
tl001@online.no
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
Attack and Release Times
Saturday, 23-Jan-99 12:42:24
199.199.157.24 writes:
Some info for the archive: I tried setting attack and release to 0 and looked at
the .wav, and it looks like the minimum attack time is about 0.2 ms. An attack
setting of 2 is about 1 ms and 3 is about 5 ms. The minimum release time is
pretty long, about 20 ms.
In some places the waveform seems to try to start at a peak instead of a zero, or
maybe it's starting a few ticks into the waveform, but that must account for that
pop you get at short attack settings.
leiter
------------------------------------------------------------------------------------------
Re: Attack and Release Times
Saturday, 23-Jan-99 17:02:54
128.8.201.10 writes:
Interesting. Is this a common problem among
synthesizers? It seemed like the synth
was never *EXACTLY* precise. Maybe those
times are what give it that feeling.
Ivan.
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------