K2 portamento/glide script

**Big Bob** · 10-20-2005, 11:34 AM

Hey guys,

I'm sorry to report that there is a 'fly in the ointment'. I completed the PCE (Pitch Control Engine) and the Demo Control Script for it and I had started on cleaning up my flow charts and preparing the documentation package in preparation to releasing it but now I'm not so sure that I should!

Now that I have a 'front-end' control program for the PCE, and I'm finally able to exercise it more thoroughly with various instrument patches, the results are not so hot! I had done most of my initial testing with a trombone patch and it still sounds good, but some other instruments aren't faring so well. Some instruments exhibit pronounced artifacts during medium to fast glissandos.

I'm looking into this now but the problem may be related to known issues with the KSP change_vol() function. I initially had trouble getting this function to work. In fact, I had to abandon using the change_vol(x,y,0) form (which is the one I really wanted to use) and use instead the change_vol( x,y,1) form in order to 'work-around' an intervening wait() problem. NI has disclosed that there are yet other problems with the change_vol() function which includes things like 'pops and cracks'. And since the PCE uses the change_vol() function to (ahem) 'smoothly' produce an equal-power crossfade, 'pops and cracks' could well explain the artifacts that I'm hearing.

On the other hand, the PCE script is kind of tricky and it's very possible that there still is some problem with the design or with my coding. So, I'm going over it now with a 'fine-tooth comb' but so far I haven't found anything wrong. Since I have already invested a lot of time on this, I hate to just abandon it but, since it's quite possible that the fault lies with NI, I don't want to burn too much more time on this.

So, if I can't nail something soon, I may decide to just wait for the next K2 release before fighting this anymore. If so, I think I'll just complete the documentation package as if everything is cool (which it might be after NI fixes the change_vol() function), and set everything aside and wait for NI's next move. I'll report back again in a few days when I will hopefully have a better handle on the situation.

Sorry for the bad news!

Bob

**fizbin** · 10-20-2005, 12:56 PM

I had experienced those same problems with change_vol in some scripting I tried at one point. In the same way that the current portamento patch uses the change_tune to slightly change the pitch every 10,000th of a second so was I trying to use change_vol to do my own fade, but while change_tune works admirably at that rate, change_vol produced a nasty noise. At the time I didn't know if it was a bug or just a limitation of change_vol, but it seems you've confirmed that it is a bug. Good work.

fizbin

**mixolydian** · 10-20-2005, 01:24 PM

Sorry to hear this.

**Big Bob** · 10-20-2005, 07:42 PM

I had experienced those same problems with change_vol in some scripting I tried at one point. In the same way that the current portamento patch uses the change_tune to slightly change the pitch every 10,000th of a second so was I trying to use change_vol to do my own fade, but while change_tune works admirably at that rate, change_vol produced a nasty noise. At the time I didn't know if it was a bug or just a limitation of change_vol, but it seems you've confirmed that it is a bug. Good work.

Hi Jay,

Thanks for the info that you too experienced some similar-sounding change_vol() problems. Maybe we should compare experiences in a little more detail. I am hearing noises that are more pronounced as the glide or slide becomes more rapid. If I put the PCE in the 'Bender' mode, it is easier to get a handle on it than when operating in the Glider mode. In Bender mode, I can assign one of my keyboard's MIDI sliders as the bender control, set the bend interval wide (say an octave) and then have complete control over how fast or slow the pitch changes by how fast or slow I move the slider.

When I move the slider slowly, I do not hear any artifacts, even though the PCE is still executing the complex process of switching samples in and out and intelligently crossfading them. But, when I move the slider more rapidly, artifacts begin to appear. The sounds I hear are similar to what you would hear in the analog world if the slider potentiometer was dirty and adding static-like noises. Its almost like some form of aliasing is generating subharmonics.

I also notice that these artifacts are much less noticeable with 'mellow' instruments like trombone or french horn and very noticeable with bright, reedy instruments like clarinet. I'm sorry that I didn't do my initial testing with a clarinet instead of a trombone patch because I may not have gotten in so deep before uncovering this problem.

After I heard how the PCE script sounded on a clarinet, I loaded your glider script and tried it on the same instrument and it was nice and smooth. I think this is another indictment of the change_vol() function. Apparently, the 'fade' functions do not produce such artifacts. Unfortunately, even though one can press the fade_in/fade_out functions into service for a glider, they're not very useable in a Bender mode. Moreover, they seem to provide something akin to linear fades and thus can't provide anything like equal-power crossfades. The change_vol() functions would also be much more flexible (that is if they worked properly).

And, you're right about the change_tune() function, in fact, it works well at any testable speed. In earlier testing, it took my 'inner seek-loop' about 25 microseconds to execute, so I could use as low as a wait(25) before losing accurate time control (on a 3.4GHz P4); change_tune continued to work without any discernable artifacts at that speed.

I have not yet found any logic or coding error in my script and I'm becoming more convinced that this is a KSP problem, especially since NI has admitted to several problems with the change_vol() function. Maybe it's time for one of us to post the 'Ultimate KSP Bug List' on NI's forum. Someone did this recently for general K2 problems, but maybe we have collected enough problems now for the KSP that it deserves its own thread?

In the meantime, I guess I'll finish up my documentation package and then set this thing aside. If anyone wants to play with it in spite of the artifacts, let me know, and I'll post it as an attachment on NI's forum. Besides hoping that NI will fix this problem soon, I guess my only other comfort for having done all this work is that I'll be able to use it with Trombone patches

.

Bob

**synergy543** · 10-20-2005, 07:54 PM

Hi Bob,

Sorry to hear about your set back. Hopefully you'll find a solution before long or NI will fix the root of the problem. Have you contacted them?

The right person at NI (whoever that is) could probably help to solve this obstacle and might provide support for your efforts.

**Big Bob** · 10-20-2005, 09:21 PM

Hi Bob,

Sorry to hear about your set back. Hopefully you'll find a solution before long or NI will fix the root of the problem. Have you contacted them?

Yes, I'm also very sorry about this sad state of affairs. I don't think that I reported this yet on NI's 'official' form, but I reported a volume-jump problem with the change_vol() function early on at the NI forum (regarding the 3rd parm = 0 form with an intervening wait() function) and Nicki Marinic responded. He not only acknowledged the problem, but he volunteered the information that they know about various audio 'cracks and pops' associated with this function. So, I assume they are aware of the situation. However, when I get done cleaning up my mess, I'm going to 'officially' report it. As I also suggested in my last post, one of us ought to start a semi-official KSP bug list and post it. Now that NI personnel such as Nicki seem to be watching their forum, maybe we will get some action (I Hope I Hope I Hope).

Bob

**g.h.** · 10-21-2005, 04:19 AM

Hi BigBob!

Sorry to hear about your setback. I also was eagerly waiting to see the results of your effort.

I have myself started recently to dig a little bit into Kontakt script programming and although I have not come by for to that stage like you or FIZBIN here is an idea which you may consider as a workaround while waiting for a bug fix from NI.

I assume the rapid movement of a controller generates a lot of call backs which may interfere each other. What if you try to "thin out" the controller data on fast movements?

Best regards
gh

**Big Bob** · 10-21-2005, 12:34 PM

I assume the rapid movement of a controller generates a lot of call backs which may interfere each other. What if you try to "thin out" the controller data on fast movements?

Hi gh,
Thanks for the suggestion but, I don't think the problem is related to any kind of data clogging or 'out of order' processing of data blocks. My inner processing loop hums along just fine at a very rapid clip and the tuning function has no problem keeping up with it. Actually there is no MIDI controller data that is bottle-necking anything. The problem is in ramping the pitch and volume of a pair of notes. Since we are trying to emulate something akin to an analog ramp, 'thinning out' data would be tantamount to stairstepping with larger steps. If the steps get too large, the ramp will no longer sound smooth (the ear will no longer integrate the steps) and a stairstepped sound would result.

Besides that, in normal operation, the ramp step size is already variable (depending on the total bend interval and the speed of the glide or tracking). Currently, the inner loop runs at a frequency of 33,000 steps per second with ramp steps ranging in size from 0.036 to 2.4 cents per step.

The problem is related to the change_vol() function generating various noises. These noises become more evident when a barrage of control commands are issued, but the rate is relatively unimportant. This same 'barrage rate' is very gracefully accepted by the change_tune() function so we're not at some inherent limit of the KSP or K2 processing speed.

To verify that the problem is not related to trying to run too fast, I have slowed the 'inner loop' down considerably with virtually no change in the artifacts. Normally, the inner loop runs every 30 microseconds (BTW fizbin's runs every 100 us) but, I have slowed that first by a factor of 10, then by a factor of 100 with no discernable improvement! In other words at an inner-loop clock tick rate of 3 milliseconds, the problem still persists. Of course even if it didn't it wouldn't be of much use since that speed would be way too slow to be useful.

However, all this being said, I did have a thought last night. I wonder if we can control instrument volume smoothly and without artifacts by adding a MIDI CC modulator to the instrument's amplifier? Even if there are no artifacts, the resolution of only 128 steps may be too course. It would also be a little hoaky since it would require an instrument edit in order to use the script, but, as a temporary 'work-around' it might be of some use. If I can find the time, I'll run some tests later today.

How about this idea fiz, when you were trying to crossfade with the change_vol() function did you try anything like that? If so and if it doesn't work well either, please let me know before I spend any time on it.

**Big Bob** · 10-21-2005, 01:07 PM

Retraction!

Boy you can probably tell that I didn't get much sleep last night! Obviously my latest idea is born out of desperation. Even it worked, one would have to assign each sample to its own group since we have to have separate volume control for each note!

I'm going to edit my last post before anyone takes it seriously.

Bob

Sorry, too late

**fizbin** · 10-21-2005, 01:08 PM

I didn't think of or try the cc control method you're talking about. I think at the time I just came to the conclusion that I had to make it work with fade_in/fade_out. For instance, you could simulate a curved fade out if you call fade_out and then call it again with a different time during the fade_out then call it again and again as necessary with different fade times until it is completely faded - then you have your curve, although only as smooth as the frequency of the calls to fade_out. The fade_out just resets itself starting at the current (mid-fade) volume and recalculates the fade - rather than doing the entire fade again. You know what I mean?

I haven't tried this in awhile - correct me if I'm wrong. It's going to take a bit of calculation. The trick will be to know what the fade_out time will be for each segment of the curve, rather than the volume change that you would calculate for each segment of the vol_change curve.

The weirdness will be that, in the case of a fade_out curve that begins steep and ends flat, the fade_out time will be very quick at first, then much longer at the end. Well, then since you don't really know what your volume is - you don't really have a number that describes your volume on a fade_out - the engine just "handles" it, how will you know when to stop fading? At some point you're going to have a very flat part of the curve and a really long fade out time. At this point it will probably be inaudible anyway, so you'd want to cut in and do a quick fade_out all of a suddent to kill the unnecessary part of the process. But how to know when you are there?

You'd probably want to set some threshold (a point where the fade_out time gets above a certain number) so that at a certain point there is one last fade_out and from there it is linear - a point in the fade where it would not matter too much.

fizbin