# Volume/Engine_Par Function



## Big Bob (Feb 5, 2008)

Hi you all :lol: 

A while back, in another thread, 
http://vi-control.net/forum/viewtopic.php?t=8393

there was some discussion of the relationship between ENGINE_PAR_VOLUME and the Volume Knob (for the amplifier module). At the time I was up to my eyeballs in other things  but I said that someday I would investigate this more thoroughly. Well, I finally got SIPS 2 off to beta testing and I started in on my backlog. 

Here is some preliminary info on the volume function. First off, the Amp Volume knob's display is fairly accurate insofar as actual audio output is concerned. And, the relationship between the Engine_par number, N, and the Volume knob display, V is given quite accurately by the following:

(1) N = 10^6 * 2^((V - 12)/18 ) 
Where N is the ep value between 0 and 1,000,000 and V is the Volume in db.
(note I'm using ^ to mean exponentiation)

Simplifying and solving for V we get:
(2) V = 18 lg(N) - 347

where lg(N) is the logarithm of N to the base 2.

and for N:

(3) N = 2^(V + 347)/18

Thus, for a given ep number, you can compute the corresponding Volume quite easily with the KSP Math Library using equation (2). As soon as I get a little more time, I'll add an antilog function to the library so that we can use equation (3) to compute the ep value needed for a given Volume in db.

To be continued :wink: 

God Bless,

Bob


----------



## Tod (Feb 5, 2008)

Hi my friend,

Hehe, you gotta make things complicated don't you.  :wink: 

So I have to ask, what are we going for here? The exact NI number that correlates with any given db value?

God bless you too and how are your feeling?

Tod


----------



## Big Bob (Feb 5, 2008)

> So I have to ask, what are we going for here? The exact NI number that correlates with any given db value?


Yep! Once we have this I can add a couple of functions to the Math Library so we can use Engine Parameters to achieve things like Equal_Power Crossfading of any pair of groups, etc.



> God bless you too and how are your feeling?


Right now pretty good! But, it sort of comes and goes these days :lol: 
However, I'm glad to see a post from you my friend. I was beginning to wonder if you were OK. I sent you an email a week or so ago and never heard back from you. Glad you are still with us o-[][]-o 

Take care Tod,

Bob


----------



## Tod (Feb 6, 2008)

Big Bob @ Tue Feb 05 said:


> > God bless you too and how are your feeling?
> 
> 
> Right now pretty good! But, it sort of comes and goes these days :lol:
> ...



Humm, not sure what might have happened to your email. I'm with Centurytel so who knows. Maybe try sending it again. :? 

I've been busy with one of my video projects but I'm about ready to move into my Bug Room to start makeing my flies and lures, hehe fishing season's not too far away. :mrgreen: 

I'm really glad your doing good and I'm anxious to see what this new addition to your math library is and how it will work. I'm assumeing that it will primarily be used with the amplifier volume or do you have a way of over-rideing the modulator scaleings? It wouldn't suprise me if you did. :D :wink: 

Tod


----------



## Thonex (Feb 6, 2008)

Very cool Bob... I tried your little formula in Excel... here is a chart of the results. Pretty close... I don't know how you do it.


```
50000	=	-66.02647146
100000	=	-48.02647146
150000	=	-37.49714645
200000	=	-30.02647146
250000	=	-24.23176575
300000	=	-19.49714645
350000	=	-15.49408286
400000	=	-12.02647146
450000	=	-8.967821434
500000	=	-6.231765752
550000	=	-3.756702325
600000	=	-1.497146447
650000	=	0.581443466
700000	=	2.505917137
750000	=	4.297559261
800000	=	5.97352854
850000	=	7.547859682
900000	=	9.032178566
950000	=	10.43622378
1000000	=	11.76823425
```

Maybe this chart will help the cause?


----------



## Tod (Feb 6, 2008)

Hi Thonex,

I made a script to get these numbers and they are very similar to yours. I'll have to look closer tomorrow but they're very similar.

I use Excel all the time but don't have a clue how to put Bob's formulas into it. Can you please show the exact formula your useing to get this? By this I mean the way you input it into Excel.

Hehe, sorry I'm an old fart. Actually Bob's older than me but then he's a genius and I love him. :D 

Tod


----------



## Thonex (Feb 6, 2008)

Tod @ Thu Feb 07 said:


> Can you please show the exact formula your useing to get this? By this I mean the way you input it into Excel.



Sure.

In an open cell C5... type this in: 

=18*LOG(B5,2)-347

B5 is the number you'll be referencing from cell B5.

next, drag the bottom right hand side of the C5 cell down to copy the contents to a bunch of cells beneath it (in the C column)

You'll see a lot of "#NUM" error messages.. just ignore that for now.

Now... in the B5 Column type the number 50000, then in the B6 Column type in the number 100000. You'll see the C column cells updating accordingly. 

Then select cells B5 and B6 and while holing Option Key, drag the bottom right border down and the cells will be filled by 50000 increments.

Viola.


----------



## Thonex (Feb 7, 2008)

Thanks for that explanation Bob. I was actually able to follow that 

But what about that "-347"? I guess that's just an offset you use to make it all add up correctly?

And again... it begs the question... *why doesn't NI share these formulas with us*???? They give us the ability to Script using KSP... yet they won't share the formulas???

I don't get it.

Thanks gain Bob.


Cheers,

T


----------



## Thonex (Feb 7, 2008)

While we're on this subject and discussing equal powered cross-fades... what was the reason we aren't using fade_in() and fade_out() commands? Was it because they were not having the same slope. Clearly the duration is equal if set to the same micro (or is it mili) seconds... no? And if not... would it be hard to figure out an offset amount so they are virtually behaving the same?

Sorry if this has already been discussed. I have "daddy brain".

Cheers,

T


----------



## Tod (Feb 7, 2008)

Hi Bob,

You may not have my current address, I just sent you an email that has it.

Thanks for the instructions Thonex, it worked great.

I don't know if this will help at all but I also made a little script some time ago for getting the K2 numbers that correlate with the db values. It works by finding the top and bottom numbers of any given db value and then calculates the mid point between the two.

Hehe, it's certainly not rocket science but I think it gives a pretty close accounting for the correct number.

In case anyone wants to check it out I attached it in a zip file. Although its quite simple and self explanatory I did put together some simple directions. You'll have to copy and paste the text into Nils editor because it has a function.

I played around with the formula a little for a -12.0db value and this is what I got:


```
Values for -12.0db

                 Actual                                        Result useing
                K2 Number                                      the formula

Top Number:      397615                                            -12.182
Mid Number:      396851                                            -12.232
Bot Number:      396087                                            -12.282
```


----------



## Big Bob (Feb 7, 2008)

> But what about that "-347"? I guess that's just an offset you use to make it all add up correctly?



Hi Andrew,

The 347 comes about after you solve the equation for Vol in terms of N. As follows:
We start with: 
N/Nmax = 2^(V - 12)/18
Then, take logs (base 2) of both sides of the equation:
Lg(N/Nmax) = (V - 12)/18
or
18*Lg(N/Nmax) +12 = V
or V = 18*[Lg(N) - Lg(Nmax)] + 12 = 18*Lg(N) - 18*Lg(Nmax) + 12

and since Lg(1000000) is about 19.93, then we have:
V = 18*Lg(N) -359 + 12 = 18*Lg(N) -347

Clear as mud?

Hi Tod,

I downloaded your script and as soon as I get a little extra time I'll check it out.

Meanwhile, the email mystery remains a mystery. I got all 3 of yours but you still don't seem to be getting any of mine. I verified your address in my address book and it seems to be correct. Besides sending a 'Reply' to one of your 3 emails, I also sent you another quickie where I hand typed your email address.

Have you been getting email from others? Have you tried sending one to yourself?

Bob


----------



## Big Bob (Feb 8, 2008)

Thonex @ Thu Feb 07 said:


> While we're on this subject and discussing equal powered cross-fades... what was the reason we aren't using fade_in() and fade_out() commands? Was it because they were not having the same slope. Clearly the duration is equal if set to the same micro (or is it mili) seconds... no? And if not... would it be hard to figure out an offset amount so they are virtually behaving the same?
> 
> Sorry if this has already been discussed. I have "daddy brain".
> 
> ...



Hi Andrew,

A number of tests (made some time ago) indicate that the fade_in/fade_out functions produce a linear volume change per unit time. Since the usual objective in crossfading two audio sources is to provide a constant volume throughout the crossfade, the two signals must be combined in such a way as to maintain equal power (equal energy per unit time). 

The shape of the crossfade curves required to do this depends on the relative correlation of the two audio signals. If the signals are perfectly correlated, then a linear crossfade is exactly what is needed. However, if the two signals are totally uncorrelated, then a sin/cos shape is required. So, if you use linear crossfading for two uncorrelated signals, you will hear a 3db dip in the middle of the xfade. Whereas if you use a sin/cos xfade, the volume will remain constant. However, if the two signals are totally correlated, then a sin/cos xfade will produce a 3db bump in the middle whereas a linear xfade will produce a constant volume transisition. 

Since most signal pairs are more or less uncorrelated, sin/cos xfades are usually superior to linear xfades. Probably the best way to write a script that does something like velocity-layer crossfading would be to provide a correlation knob such that when the knob is set to 100%, the xfade would be linear and when the knob was set to 0%, the xfade would use sin/cos shaping. Then for 'in-between' correlation settings, the xfade curve would be some 'in-between blend' of linear and sin/cos shaping. Obviously, the fade_in/fade_out functions alone couldn't provide this. In addition, for something like formant-corrected pitch bending you have to be able to vary the xfade rate or even 'stop it in the middle'. This cannot be done conveniently with the fade_in/fade_out functions.

I got involved with the ep versus volume relationship because I was thinking about the best way to mate a velocity-layer xfade script with SIPS 2. For SIPS 1.5, the way Nils and I were going to mate his VXF script with SIPS was to have SIPS generate 'sets' of notes (one for each velocity layer). However, this gives rise to some rather tight coupling between the scripts and makes the KSP work rather hard, especially after adding the portamento mode to the SLS.

Since SIPS 2 now includes an articulation script that allows multiple groups to be assigned to each articulation index, it seems like a better way to handle VLXF is to assign each velocity layer to a separate group. That way, the SLS doesn't have to generate note 'sets' but, it does require that we be able to control the volume of pairs of groups to effect the xfade. This means we would need to use the engine par stuff instead of the change_vol() function to perform the xfade. In order to do that, I needed to make sure that the ep vs volume function wasn't some strange curve that would require a big lookup table to work with.

Fortunately, the ep vs volume relationship is fairly straight forward (as indicated with the formulae I posted). In fact, for EPXF control shaping, one could forget about db entirely and just use the linear ratio relationships between ep and volume. Note that in terms of ordinary volume ratios (instead of logarthimic/db), the relationship between ep and volume could be expressed this way.

(V/Vmax) = (N/Nmax )^3

Where V/Vmax is the volume ratio and N/Nmax is the engine parameter ratio. Thus, a crossfade script would only need to be able to take the cube root of the volume ratio in order to determine the ep value needed.

As I indicated earlier, when I get some uninterrupted time, I'll begin thinking more seriously about this and then I'll probably expand the Math Library in some appropriate way to enable us to use ep control of group volume to effect fancy xfades. That is, the Good Lord willing and the creek don't rise :lol: 

God Bless,

Bob


----------



## Tod (Feb 8, 2008)

Hi Bob,

Well the email with the SIPS didn't come through. Obviously there is a problem on my end with the server and I'm not sure what to do about it. I've tried several times to find an account for me that I could deal with it but got no where. I guess I need to call them but calling centurytel support means 3 to 4 hours of sitting on the phone (actually it can be a whole days experience). :evil: 

Since I got your other two emails maybe you could change the subject line.

Concerning what your talking about in your last post, I've got some really stupid questions to ask :oops: but I need to read through it a little more.

Bless you and hopefully the creek is'n't going through your back yard.  

Tod


----------



## Thonex (Feb 8, 2008)

That clear and concise breakdown !! I really appreciate the details.



Big Bob @ Fri Feb 08 said:


> The shape of the crossfade curves required to do this depends on the relative correlation of the two audio signals. If the signals are perfectly correlated, then a linear crossfade is exactly what is needed. However, if the two signals are totally uncorrelated, then a sin/cos shape is required. So, if you use linear crossfading for two uncorrelated signals, you will hear a 3db dip in the middle of the xfade. Whereas if you use a sin/cos xfade, the volume will remain constant. However, if the two signals are totally correlated, then a sin/cos xfade will produce a 3db bump in the middle whereas a linear xfade will produce a constant volume transisition.



I had no idea that linear would give equal power xfades on only correlated signals while sin/cos would do it for uncorrelated. This seems counterintuitive to me. I always just thought that it didn't matter if it was linear or cos/sin... as long as the volumes gains/reductions were perfectly inversely proportional. Thanks for clearing this up for me.

Also, obviously the benefit of not using fade_in/out comes into play when trying to xfade with a CC. I don't think there is a practical way to implement fade_in/out commands in the context of controlling them with CC.

Anyway Bob... thanks for the lesson. o-[][]-o 

Cheers,

Andrew


----------



## Tod (Feb 8, 2008)

Hi Bob,



> The shape of the crossfade curves required to do this depends on the relative correlation of the two audio signals. If the signals are perfectly correlated, then a linear crossfade is exactly what is needed.



I know this is a stupid question but what exactly do you mean by "correlation"? That their volumes are equal or are you talking about frequency content too?

I don't know if this will be of any help but by useing the script that I posted above, here are some of the numbers I came up with.


```
$Vol_Num [0] = 1000000  {12 db}
$Vol_Num [1] = 962225  {11 db}
$Vol_Num [2] = 925876  {10 db}
$Vol_Num [3] = 890900  {9 db}
$Vol_Num [4] = 857246  {8 db}
$Vol_Num [5] = 824862  {7 db}
$Vol_Num [6] = 793700  {6 db}
$Vol_Num [7] = 763719  {5 db}
$Vol_Num [8] = 734868  {4 db}
$Vol_Num [9] = 707108  {3 db}
$Vol_Num [10] = 680396  {2 db}
$Vol_Num [11] = 654693  {1 db}
$Vol_Num [12] = 630567  {0.0 db}
$Vol_Num [13] = 561232  {-3 db}
$Vol_Num [14] = 500000  {-6 db}
$Vol_Num [15] = 445450  {-9 db}
$Vol_Num [16] = 396850  {-12 db}
$Vol_Num [17] = 353554  {-15 db}
$Vol_Num [18] = 314981  {-18 db}
$Vol_Num [19] = 280616  {-21 db}
$Vol_Num [20] = 250000  {-24 db}
$Vol_Num [21] = 222725  {-27 db}
$Vol_Num [22] = 198425  {-30 db}
$Vol_Num [23] = 176777  {-33 db}
$Vol_Num [24] = 157490  {-36 db}
$Vol_Num [25] = 140308  {-39 db}
$Vol_Num [26] = 125000  {-42 db}
$Vol_Num [27] = 111362  {-45 db}
$Vol_Num [28] = 99212  {-48 db}
$Vol_Num [29] = 88388  {-51 db}
$Vol_Num [30] = 78745  {-54 db}
$Vol_Num [31] = 70154  {-57 db}
$Vol_Num [32] = 62500  {-60 db}
```

The reason I show this with an array is because I use Excel to make the text so I can just paste it into Nils editor. Also if anyone wants to use it for any reason *take note* that I goofed up and used a "$" instead of "%" but that's very easy to change with Nils editor.

Tod


----------



## Big Bob (Feb 8, 2008)

> Yes, I was looking at that. Hehe, I know .1db, .2db or even .5db isn't much but I've always had a tendency for going for broke.



Hi Tod,

I spot checked a few of your tablulated values and if you use accurate math and the -346.768 value, every tabulated entry that I checked seems to be accurate to less than 0.001db, EXCEPT for 0.0db which was something like 0.02db off. *However, I think that is due to an error in your tabulation. *I ran your script and got the following for 0.0db:

628749 min, 631174 max, 629961 nominal

Using the 629961 value, the calculated Volume is then 0.0002538 db which is again less than 0.001db error.

Check your tabulation and see if you concur o/~ 

Bob


----------



## Tod (Feb 8, 2008)

Hi Bob,




> I spot checked a few of your tablulated values and if you use accurate math and the -346.768 value, every tabulated entry that I checked seems to be accurate to less than 0.001db, EXCEPT for 0.0db which was something like 0.02db off. However, I think that is due to an error in your tabulation. I ran your script and got the following for 0.0db:
> 
> 628749 min, 631174 max, 629961 nominal



Yes, there might be a few that are slightly off although I'm not sure. Sometimes I'll put a zero on the end.  However, when I recalculate 0.0db useing the script this is what I get:

629961-Min, 631174-Max, and 630567-Calculated mid. Actually I think that's what I showed for 0.0db. 

I wonder if our versions of K2 might have something to do with it? :? 

Tod


----------



## Big Bob (Feb 8, 2008)

> I wonder if our versions of K2 might have something to do with it?


I'm running K2.2.3 standalone and I get the 3 numbers I reported (when I use your script). Besides, your tabulated 0.0db value is the ONLY one in your tabulation with such a big error (0.02db) so I think there must be something wrong at your end. But, I guess it's not worth spending any more time on since our difference is rather small.

God Bless,

Bob


----------



## Thonex (Feb 9, 2008)

Big Bob @ Fri Feb 08 said:


> Hi Tod,
> 
> I spot checked a few of your tablulated values and if you use accurate math and the -346.768 value, every tabulated entry that I checked seems to be accurate to less than 0.001db,



HI Bob,

Because of the decimal use limitations in KSP, how difficult would it be to rework the formula so that it would always somehow add 0.232db to the "rounded" -347 calculation as opposed to using the more accurate -346.768 calculation?

I can't think of one off the top of my head... is there a way?

Thanks,

T


----------



## Big Bob (Feb 9, 2008)

> Because of the decimal use limitations in KSP, how difficult would it be to rework the formula so that it would always somehow add 0.232db to the "rounded" -347 calculation as opposed to using the more accurate -346.768 calculation?
> 
> I can't think of one off the top of my head... is there a way?



Hi Andrew,

I guess the answer to your question depends on how you intend to compute lg(N) and what you will do with Vol after you calculate it. If you are just trying to keep everything in the integer domain, you could re-write the formula to compute Volume in mdb as follows:

Vol = 18000Lg(N) - 346768 where Vol is in mdb and Lg is log to the base 2

However, if you intend to use the KSP Math Library to do the log calculation, two other things must be considered. The current version of the Log2 function requires an input less than 16384 and, generates the log scaled up by 10000. Since N can be any value from 0 to 1000000, we have to recast the above equation as follows:

Vol = 18000[(N/64) + Lg(64)] - 346768
or
Vol = 18000Lg(N') + 108000 - 346768 where N' = N/64
or
Vol = 18000Lg(N') - 238768

Now, using the math library Log2 function (remember its result is scaled by 10000),
Vol = 1.8*Log2(N') - 238768 where N' = N/64 and Vol is in mdb

And then to get rid of the remaining fraction of 1.8 we can re-write it as:
Vol = 18*Log2(N')/10 - 238768 where N' = N/64

And, since N' results in down-scaling of N, we can reduce truncation errors by rounding the N/64 operation as follows: N' = (N + 32)/64 

Thus our final formula is:

Vol = 18*Log2((N+32)/64) - 238768

where N is the Engine Par value from 0 to 1000000 and Vol is in mdb. This is essentially the fraction-free equation I used in my little demo script.

All that being said, why are you interested in doing this calculation? ie what will you do with the result? The reason I wrote the demo script was to illustrate how well my function tracks NI's volume control. But other than that, what good is it? If all you are going to do after calculating Volume is to display it some way, you could do that without the formula by using _get_engine_par_disp. *The real value of my equation is that it can be mathematically reversed and that will allow us to calculate N for a given V/Vmax.*

Right now we can't do that because we would need either an Antilog or cube-root function which currently is not in our math library. The function I'm actually thinking of adding to the Math Library will accept V/Vmax scaled by 10000 as input and then return the corresponding value of N required to produce that volume ratio.

With such a function, we could then use the SinCos function followed by our new function to compute the N values needed to do an EPXF of a pair of groups for example. However, until I cook up this new function, I don't think there will be much use for the volume formula. But, maybe I'm missing something? :? 

God Bless,

Bob


----------



## Thonex (Feb 9, 2008)

Hi Bob

Thanks for that in depth explanation. I'm going to have to print that out so I can look at it more closely (I'm kinda weird that way). The funny thing is, my high school math teacher (an ex-math professor at Columbia University) was trying to encourage me to go into math/physics as opposed to music. In retrospect, I think I made the right choice :lol: 




Big Bob @ Sat Feb 09 said:


> All that being said, why are you interested in doing this calculation? ie what will you do with the result? The reason I wrote the demo script was to illustrate how well my function tracks NI's volume control. But other than that, what good is it? If all you are going to do after calculating Volume is to display it some way, you could do that without the formula by using _get_engine_par_disp. *The real value of my equation is that it can be mathematically reversed and that will allow us to calculate N for a given V/Vmax.*



Well... to be honest... I hadn't gotten that far yet. I first wanted to understand if/how it was possible to make the equation non-decimal friendly and still be accurate. I'm always coming up with scripting ideas... and ways to improve patches... but raising a family and actually composing for a living doesn't leave me the time to do all the scripting I'd like to.

And you are right, it's the reverse of that equation (solving for N) that would probably be most useful. 

I've actually written some formant-correct pitch bend scripts that work quite well and are very transparent with fade_in/out commands, but I'm sure (because of your correlation explanation) that a sin/cos curve would be better. But I get intimidated by scripts that use heavy calculations within loops... for the obvious reasons of keeping track of releases and choking off notes when another note is played before the loop has run it's course... etc...etc. 

I think it basically comes down to that I'm not that great a programmer... and I'm trying to understand some of these principals as the arise.

Thanks again for all this great info Bob. It's like going back to school.. and that's a good thing.

Cheers,

T


----------



## Tod (Feb 9, 2008)

Hi Thonex and Bob,

Both of you have mentioned "Formant Correct". Now I understand what formant is (at least how it relates to speach) and it don't take a lot of imagination to see how it might relate to samples too. What I don't understand is what, why, and how you are correcting it? Actuallly I think if I knew "what" you're correctiing I'll probably understand the rest. :oops: :roll: 

If this is too difficult to easily explain or takes to much time to easily explain *please*, *please* don't worry about it.



> Thanks again for all this great info Bob. It's like going back to school.. and that's a good thing.



Amen to that, it's been nearly 50 years.  

Tod


----------



## Big Bob (Feb 9, 2008)

> What I don't understand is what, why, and how you are correcting it? Actuallly I think if I knew "what" you're correctiing I'll probably understand the rest.



Hi Tod,

The issue we are refering to is formant-corrected pitch bending. Think of it this way, in the old days of 2-speed tape decks, if you played a vocal back at twice its recorded speed, it would raise the pitch by an octave but it no longer sounded normal. The effect was often called the 'chipmunk' effect after a guy named David Seville capitalized on it with some hit recordings of 'Alvin and the Chipmunks'.

To raise the pitch of a vocal or any instrument for that matter, you have to do more than just raise the effective playback speed because that also raises the pitch of the formants which you don't want to do if you want it to remain natural sounding.

When you play a note in K2 and then use the pitch bender to change its pitch, the formants are changed also and the effect isn't natural over wider intervals. If it was, you wouldn't have to multi-sample instruments, one sample would do the job.

What Andrew is refering to with formant-corrected pitch bending works something like this. Assume you have a multisampled instrument with samples every semitone. Now lets say you play C3 and want to slide up to G3. What the script does as it bends C3 upward, is to also start playing C#3 (but pitched down to C and muted at first). Then as the pitch of both the C3 and C#3 rises, the volume of the C3 starts fading out and the volume of the retuned C#3 starts fading in. Eventually they cross over at some point where each note makes an equal contribution to the timbre. Then as you continue to bend, the original C3 eventually dies away completely to silence and the C#3 comes up to full volume.

Similarly, when you continue raising the pitch, D3 is started (but tuned down to C#3) and then it is crossfaded with the C#3. This continues until you finally reach your destination where only G3 will be sounding. To do this in such a way that the volume remains uniform during the crossfades, the fade-in and fade-out curve needs to be shaped as a Sine/Cosine curve.

You can find this technique used in an old experimental script of mine that I called the PCE (for Pitch Control Engine). It took a long time but at last I have finally refined the technique sufficiently to include it in V2 of SIPS. The idea of course is to allow you to produce very realistic sounding glissandos of almost any kind and over very wide intervals if desired.

Have a great day my friend,

God Bless,

Bob


----------



## Tod (Feb 9, 2008)

Great explanation my friend, I understand totally. It's such an obvious way to do it that I've thought about doing this myself, figureing and knowing full well it was nothing new, but I didn't know what it was called. :oops: :roll: 

Also I'd just assumed you had already incorporated this technique into SIPS. Actually, early on with SIPS I think I remember you talking about this.

Any way, now I know what "Formant Correct" means and I thankyou. :D 

God bless you,

Tod


----------

