K2 portamento/glide script [Archive]

fizbin

04-16-2005, 05:51 PM

This script allows a portamento pitch slide between keys. It not only changes pitch but crossfades between samples as the pitch slide occurs so that an appropriate sample is mapped to the pitch that is slid to.

examples:
Gliding through memories (http://www.theokrueger.com/main/Audio/Gliding_through_memories.mp3) - Choir Glide (by Theodore Keuger)
Some are to forget (http://www.theokrueger.com/main/Audio/Some_are_to_forget.mp3) - Strings Glide (by Theodore Krueger)
Desert Song (http://www.paulwaring.co.uk/docs/music/Desert.mp3) - by Paul Waring

Directions:
1. Start Kontakt 2 and load a sus or legato type patch.
2. Open the script editor and paste the script from below into it
3. Hit "apply"

The "glide" knob defines the glide time in seconds.

The "start" knob defines the sample playback offset in seconds for all samples that are "slid to". It has no effect in dfd mode - it only works in Kontakt sampler mode.

Scaling is the amount that the glide time increases over an octave. If it is set to 1 then the glide time is the same regardless of the interval. If it is set to 2 then every octave interval's glide time is twice the previous one. EDIT: Actually, the first octave interval is twice the glide time of no interval, the glide time for the 2nd octave interval is three times that of no interval and so forth. (thanks for pointing that out Bob) :-)

Threshold is the interval at which scaling stops. If it is 7 (a fifth) then the glide time is no longer increased once a fifth up or down is reached as the portamento interval.

http://tunefulmoon.com/mp3/porta/porta.gif

on init
declare const $pitch_change_interval := 100
declare $glide_on
declare $currentnote_id
declare $newnote_id
declare $oldnote1_id
declare $oldnote2_id
declare $oldnote3_id
declare $current_pitch
declare $target_pitch
declare $pitch_shift
declare $actual_glide
declare $interval_cents
declare polyphonic $this_id

declare ui_knob $Glide(1000, 1000000, 1000000)
declare ui_knob $Start (0, 1000000, 1000000)
declare ui_knob $Scaling(100, 200, 100)
declare ui_value_edit $Threshold(0, 127, 1)

$Glide := 120000
$Start := 5000
$Scaling := 125
$Threshold := 12

move_control($Glide, 1, 1)
move_control($Start, 2, 1)
move_control($Scaling, 3, 1)
move_control($Threshold, 4, 1)

make_persistent ($Start)
make_persistent ($Glide)
make_persistent ($Scaling)
make_persistent ($Threshold)

message("")
end on

on note
if ($glide_on = 1)
ignore_event($EVENT_ID)
$newnote_id := play_note($EVENT_NOTE, $EVENT_VELOCITY, $Start, -1)
$this_id := $newnote_id
change_tune($newnote_id,$current_pitch - ($EVENT_NOTE*100000), 0)
$target_pitch := $EVENT_NOTE * 100000
$interval_cents := abs($target_pitch/1000 - $current_pitch/1000)
if ($interval_cents > $Threshold * 100)
$interval_cents := $Threshold * 100
end if
$actual_glide := $Glide + ($Glide * $interval_cents / 1200 * ($Scaling - 100) / 100)

fade_out($newnote_id, 0, 1)
fade_in ($newnote_id,$actual_glide)
fade_out($currentnote_id, $actual_glide, 1)

note_off($oldnote3_id)
$oldnote3_id := $oldnote2_id
$oldnote2_id := $oldnote1_id
$oldnote1_id := $currentnote_id
$currentnote_id := $newnote_id

$pitch_shift := ($target_pitch - $current_pitch) / ($actual_glide / $pitch_change_interval)
wait($pitch_change_interval)
while(abs($target_pitch - $current_pitch) > abs($pitch_shift))
if ($currentnote_id = $this_id)
change_tune($currentnote_id, $pitch_shift, 1)
change_tune($oldnote1_id, $pitch_shift, 1)
change_tune($oldnote2_id, $pitch_shift, 1)
change_tune($oldnote3_id, $pitch_shift, 1)
$current_pitch := $current_pitch + $pitch_shift
wait($pitch_change_interval)
else
exit
end if
end while
if ($currentnote_id = $this_id)
$pitch_shift := $target_pitch - $current_pitch
change_tune($currentnote_id, $pitch_shift, 1)
change_tune($oldnote1_id, $pitch_shift, 1)
change_tune($oldnote2_id, $pitch_shift, 1)
change_tune($oldnote3_id, $pitch_shift, 1)
$current_pitch := $target_pitch
end if
else
$currentnote_id := $EVENT_ID
$current_pitch := $EVENT_NOTE * 100000
$glide_on := 1
end if
end on

on release
if($EVENT_ID = $currentnote_id)
$glide_on := 0
note_off($oldnote3_id)
note_off($oldnote2_id)
note_off($oldnote1_id)
$current_pitch := $target_pitch
end if
if ($glide_on = 1 and $EVENT_ID # $oldnote3_id)
ignore_event($EVENT_ID)
wait($Glide)
note_off($EVENT_ID)
end if
end on

You are free to use these scripts with your own samples. If you are a developer and would like to use them in your commercial library, contact me (jcoover * @ * tunefulmoon.com) and the cost to you to use them will probably be just a copy of your library :-) I am also available for custom script development.

Rich Pell

04-16-2005, 11:21 PM

thanks Fizbin..I`llhave to check that out when i pick up my copy on Monday...Keep Skriptin` :) ..Rich

bluedog

04-19-2005, 06:48 AM

Hi Fizbin,

Well just to say that it is refreshing to see someone taking off into real wor with K2 - which I think to be very good - while most of us are struggling somewhat to get some basics off the ground!

(erm...should you come across one or the other of my questions in this forum, you might have simple answers for them
:confused:

Regards
B

Jesse Hopkins

08-20-2005, 10:06 PM

Dave Bourke

08-21-2005, 04:45 PM

Many thanks for this script, Fizbin. Much appreciated. Will give it a spin when I get a chance (nursing a sick doggie right now).

Kind regards.

Big Bob

08-21-2005, 11:17 PM

Thanks fizbin,

I haven't had a chance to try it yet either, but, I'm sure it'll be another winner!

Bob

fizbin

08-22-2005, 10:20 PM

I thought that this had been forgotten. Someone knows how to use the forum search :-)

This script works well with certain sources. If a sample has a slow attack (e.g. strings) it works less well. This can be corrected, I believe by fading out the first sample a little later than normal, while the second one is not faded in by script, since it has a natural fade in. I was going to add this but didn't think many were interested.

There was another script I wrote early on that performed an artificial sforzando or sforzatto or whatever its called. That was here -> http://www.northernsounds.com/forum/showthread.php?t=33601

Big Bob

08-22-2005, 11:37 PM

Hey Fiz,
Thanks for the new link, now I've got more goodies to curl up with one of these evenings.

I was going to add this but didn't think many were interested.

I'm glad this stuff has been 're-discovered'. You were just way ahead of your time! Keep 'em coming because I'm sure you have a much bigger audience now.

Bob

fizbin

08-23-2005, 07:34 PM

Hey! This is excellent! I have been using it all day! Is there any chance of controlling the parameters with a CC though?

For strings, it could be good if there was some way to chorus just during the gliss, because 20 players rarely are in perfect sync. But this is truly excellent. Bravo!

Oh, just thought of something else. A tempo sync version would be good, where one could choose 16th, 8th, quarter note on a dial instead of fractions of a second.

Overture 4 users should note that this will make it possible to use the gliss function to smoothly go between all chromatic samples in a long gliss. Pretty realistic!

I think you could add CC control to it. The crossfade happens only during the slide. You could add tempo synch too, replacing the gliss knob values with environment variable values for the note durations. You could also add key switching to this (going back and forth between normal and portamento mode). This is just the basic version of the script.

mixolydian

08-25-2005, 10:29 AM

Jay, your script is awesome! I'm new to Kontakt (arrived this week) and yesterday I've tried the portamento-script. I'm only a hobbyist but these portamento-stuff is definitely one thing I've been yearning to (tried it hardly with pitchbend and some "filling notes", but it doesn't work well and means many work for every gliding note).

Many many thanks for the great tool and that you sharing your work with us!!

Best regards.

Theodor

08-26-2005, 04:10 PM

Thanks, thanks!!!!!!!!!!! *claps

Fizbin you rocked man, this is great and very inspiring.

NI should use this instead of the current sloppy glide feature in K2.

All the best to you sir!

Theodor

08-26-2005, 06:19 PM

Back! Just wanted to say this is the best sample glide i've heard in any sampler to date. Very, very well done Jay. The scaling feature is also great and very clever.

I tested the script by loading the same Choir patch 4 times, re-pitching each load so there are different samples 4 times on the same key and then adding your script to 3 of the choir patches in the multi with different glide times. Then i turned the volume of those 3 down and made the first one have a large release.......... SOUNDS BEAUTIFUL!

Strings legato, choirs, flutes, everything is better with this!

Sorry to sound like a kindergarden kid but i'm really excited. I'll be using it all the time :)

Here's a small thing i just made up on the keyboard with the 5 x Choir and the script. The music is pretty crap but hey, the script works and especially in a full mix it will sound totally real.

Gliding through memories (www.theokrueger.com/main/Audio/Gliding_through_memories.mp3) - Choir Glide

And this is one with the same trick as the choir but with EWQLSO strings:

Some are to forget (www.theokrueger.com/main/Audio/Some_are_to_forget.mp3) - Strings Glide

Now i gotta sleep cause you kept me here all night and its 6:18 AM ! Even the rooster likes your legato man.

Thanks Jay, you're the man

fizbin

08-26-2005, 10:23 PM

Sounds great Theo - I'm glad someone is using it.
:-)
fizbin

Big Bob

08-27-2005, 12:10 AM

Theodor

08-27-2005, 02:27 AM

Just our of curiosity, is there any possibility of seeing a script that will re-pitch the same sample instead of gliding towards a newly played sampled?

I think that has its uses as well for some situtations and can really help the synth side of Kontakt 2 eg: Playing a simple sine wave this way would make it sound like an oscillator.

So as long as you are playing legato, it will be playing the same sample

Cheers

fizbin

08-27-2005, 04:33 AM

Hey Jay,
I'll join in with the KUDOS! I finally got around to playing with it, and, like Theo says, it does inspire ideas. I'm especially interested in some 'slide trombone' possibilities.

Would you mind if I massaged it a little? Perhaps I could incorporate some of Jesse Hopkins' ideas and some others that I'm sure will occur to me once I get into it.

You should come up with an honorary name for this technique, but, be careful that it doesn't set Jimi off!;)

Seriously, if you don't mind my writing another script based on your idea, I want to ask you a few questions about certain details of your code. Let me know how this sits with you.

Bob

Hack away Bob. Looking at it now, there are certain things that seem difficult to remember the purpose of in the script (having written it 4 months ago) - I gotta get better at commenting the code. That would help the reverse engineering process. One potentially confusing thing I can explain is that there are 4 voices in the script, but more than 2 will only ever play if the glide time is relatively high and you hit a 3rd (or 4th) note before the 1st one glides into the second one and so forth. That's what those notes are there for - it seemed better to keep a handle on them during the fading and let them fade out on their own while continuing the pitch bend. If for some reason a fifth note squeaked in before the initial fade/glide time ended, the oldest note would get dropped, but hopefully would be low enough in volume at that point so that it would not be noticed. Make sense? Under normal circumstances you're hearing at most 2 notes crossfading during the pitch bend. The extra 2 voices are there for the not-normal circumstances.

As for honorary names, I thought about "The Coover Maneuver", then "fizbending", but finally settled on "Portamento". What do you think? It's got a nice ring to it.

fizbin

fizbin

08-27-2005, 04:35 AM

Theodor

08-27-2005, 05:29 AM

I think "Fizbending" sounds neat man, its technical and could become a standard. "Portamento" is a bit generic :- )

DoctorZeus

08-27-2005, 06:31 AM

This works brilliantly!! One thing, though. Since you had to load 4 instances of the patch, there is no way to edit a portamento strings, for example, save it as a single instrument and load it at will... or have I got that wrong? I've only just got Kontakt2 so I may be wrong. You could save a multi, of course but then you couldn't open your portamento strings in an existing multi you were working with.

What would work, would be if the script could be edited to include a control to make it only work on a selected group (or group*s*, even better!).

Is this possible?

That way, rather than loading seperate instances of the instrument, you could copy the group several times, change the key mappings and volumes as before (but of the different group copies this time), open several instances of the script (up to 5, right?) and have them apply to different groups.

Then you can save the instrument complete.

Hope this can be done! Great work!

Back! Just wanted to say this is the best sample glide i've heard in any sampler to date. Very, very well done Jay. The scaling feature is also great and very clever.

I tested the script by loading the same Choir patch 4 times, re-pitching each load so there are different samples 4 times on the same key and then adding your script to 3 of the choir patches in the multi with different glide times. Then i turned the volume of those 3 down and made the first one have a large release.......... SOUNDS BEAUTIFUL!

Strings legato, choirs, flutes, everything is better with this!

Sorry to sound like a kindergarden kid but i'm really excited. I'll be using it all the time :)

Here's a small thing i just made up on the keyboard with the 5 x Choir and the script. The music is pretty crap but hey, the script works and especially in a full mix it will sound totally real.

Gliding through memories (www.theokrueger.com/main/Audio/Gliding_through_memories.mp3) - Choir Glide

And this is one with the same trick as the choir but with EWQLSO strings:

Some are to forget (www.theokrueger.com/main/Audio/Some_are_to_forget.mp3) - Strings Glide

Now i gotta sleep cause you kept me here all night and its 6:18 AM ! Even the rooster likes your legato man.

Thanks Jay, you're the man

fizbin

08-27-2005, 01:12 PM

There is no feasible way to make the portamento effect work polyphonically on a single patch. There is no way for the script to know which notes you want to be glided to and which notes are polyphony notes. You see?

That's why Theo had to load as many instances as needed voices.

Regarding groups, if the groups are playing simultaneously, then only one instance of the patch is still necessary. You would still just be playing a multi-layered patch in monophonic mode. Only one real pitched note will occur - but more than one layer could be playing.

fizbin

DoctorZeus

08-27-2005, 02:49 PM

I *think* you have misunderstood me. I didn't want the portamento effect to work polyphonically and I *think* Theo loaded several instances, not to create a polyphonic part (chords or counter melody etc) but to layer several "slides", with different glide parameters, low in the mix to create a more realistic string slide. That is what I did, copying Theo's example, and it worked really well.

No, what I was asking, was is it possible to add a control to make your script only act on a particular group in the instrument? In Bob's ultraTKT script there is a control to allow you to select the "release trigger" group and mute it so I thought it might well be possible to add a control to your script to make the script only act on a selected group...

... is this possible?

Thanks. :)

There is no feasible way to make the portamento effect work polyphonically on a single patch. There is no way for the script to know which notes you want to be glided to and which notes are polyphony notes. You see?

That's why Theo had to load as many instances as needed voices.

Regarding groups, if the groups are playing simultaneously, then only one instance of the patch is still necessary. You would still just be playing a multi-layered patch in monophonic mode. Only one real pitched note will occur - but more than one layer could be playing.

fizbin

Big Bob

08-27-2005, 03:07 PM

As for honorary names, I thought about "The Coover Maneuver", then "fizbending", but finally settled on "Portamento". What do you think? It's got a nice ring to it.

Hey Jay,
Like Theo, I also like 'fizbending', but, 'The Coover Maneuver' is really cute. I agree with Theo about 'Portamento', no pizazz and it doesn't add anything new to our jargon. If we use 'fizbending' with the lower-case 'f', it will really be honorary like some of the honorary scientific units such as ohm, volt, or db.

Hack away Bob. Looking at it now, there are certain things that seem difficult to remember the purpose of in the script (having written it 4 months ago) - I gotta get better at commenting the code. That would help the reverse engineering process.

I only have a couple of questions about the code. One is usage of a fade_out before the fade_in of the newnote. It seems like an unnecessary step but I'm sure you had a reason for it.

The second area that needs some discussion relates to the calculation of 'actual_glide' time. For simplicity, let's remove the scaling needed for the integer arithmetic and just talk in mathematical terms. The function you're using appears to be:

actual_glide = G[1 + (Int/12)*S]

Where: Int is the glide pitch interval in semi-tones, S is the scaling function which ranges from 1.00 to 2.00 in value, and G is the Glide time set by the knob. Finally, actual_glide is the total time interval used to glide linearly over the pitch interval, Int. Obviously, the total glide time increases as the glide pitch interval increases (and more so as S is increased from min to max), but, it's not directly proportional (because of the presence of the plus 1) and I'm not quite sure I understand the musical significance of this function. Since I'm sure you must have had a good reason for choosing this kind of function, I thought perhaps you could elaborate on the whys?

A little clarification here and there up front, might save me the painful experience of 're-discovering' something that you already suffered through.

Again, thanks for your generous contributions to the K2 community.

Big Bob

08-27-2005, 03:15 PM

No, what I was asking, was is it possible to add a control to make your script only act on a particular group in the instrument? In Bob's ultraTKT script there is a control to allow you to select the "release trigger" group and mute it so I thought it might well be possible to add a control to your script to make the script only act on a selected group...

... is this possible?

Thanks. http://www.northernsounds.com/forum/images/smilies/smile.gif
Jay, I think this question was directed at you, but since I happened to be here I thought I'd chime in. Doc, if you are using something like key switching to select groups, you could intercept the KS commands and then decide whether to use or not use 'fizbending' based on other script settings. So the answer is a qualified 'maybe' depending on the specifics.

Bob

DoctorZeus

08-27-2005, 03:24 PM

Hi Bob,

Thanks. No, I'm not using key switching to select groups. I would have several groups playing at the same time. What I am looking for is a way for the script to only act on one particular (selectable) group within the instrument - other groups would play normally.

Is this possible?

Jay, I think this question was directed at you, but since I happened to be here I thought I'd chime in. Doc, if you are using something like key switching to select groups, you could intercept the KS commands and then decide whether to use or not use 'fizbending' based on other script settings. So the answer is a qualified 'maybe' depending on the specifics.

Bob

fizbin

08-27-2005, 04:59 PM

Hey Jay,
I only have a couple of questions about the code. One is usage of a fade_out before the fade_in of the newnote. It seems like an unnecessary step but I'm sure you had a reason for it.

If I remember correctly, there was no other way to do a fade in from 0 volume on a script-played note other than to play it, immediately fade it out (i.e. 0 length fade) then fade it in again at the desired rate. You're welcome to try it out in other ways.

The second area that needs some discussion relates to the calculation of 'actual_glide' time. For simplicity, let's remove the scaling needed for the integer arithmetic and just talk in mathematical terms. The function you're using appears to be:

actual_glide = G[1 + (Int/12)*S]

Where: Int is the glide pitch interval in semi-tones, S is the scaling function which ranges from 1.00 to 2.00 in value, and G is the Glide time set by the knob. Finally, actual_glide is the total time interval used to glide linearly over the pitch interval, Int. Obviously, the total glide time increases as the glide pitch interval increases (and more so as S is increased from min to max), but, it's not directly proportional (because of the presence of the plus 1) and I'm not quite sure I understand the musical significance of this function. Since I'm sure you must have had a good reason for choosing this kind of function, I thought perhaps you could elaborate on the whys?

I'm a little rusty on formal math skills, but I did spend quite a bit of time getting this one right in my mind. The equation isn't really laid out too intuitively due to the limitations of integer math. In integer math you want to avoid a division that will lose you a lot of resolution (e.g. 66/100 = 0 in integer math) so you have to use large integers sometimes and lay it out so that no important truncations occur. I'm not sure what you mean by the "+1". This is the equation in my script.

$actual_glide := $Glide + ($Glide * $interval_cents / 1200 * ($Scaling - 100) / 100)

fizbin

fizbin

08-27-2005, 05:03 PM

Hi Bob,

Thanks. No, I'm not using key switching to select groups. I would have several groups playing at the same time. What I am looking for is a way for the script to only act on one particular (selectable) group within the instrument - other groups would play normally.

Is this possible?

I don't think so. While you can enable and disable groups by script. You don't really get a handle to a group in the script to manipulate it seperately. You play a note and get a handle on a note, which can include layers from different groups, but you can only affect the note and then all groups played by that note as a whole. I'd love to know if I'm wrong.

fizbin

Big Bob

08-27-2005, 05:07 PM

Hi Bob,

Thanks. No, I'm not using key switching to select groups. I would have several groups playing at the same time. What I am looking for is a way for the script to only act on one particular (selectable) group within the instrument - other groups would play normally.

Is this possible?
Maybe fizbin knows some way to do this but I can't think of any right off hand. NI only provided a way to have the script 'enable' and 'disable' certain groups from responding to the processed MIDI data and I don't think this will allow you to do what you're asking. But, wait till Jay checks in, he may have a different angle on things.

Bob

Whoops, Looks like Jay checked in before I could get this posted.

Big Bob

08-27-2005, 05:52 PM

I'm a little rusty on formal math skills, but I did spend quite a bit of time getting this one right in my mind. The equation isn't really laid out too intuitively due to the limitations of integer math. In integer math you want to avoid a division that will lose you a lot of resolution (e.g. 66/100 = 0 in integer math) so you have to use large integers sometimes and lay it out so that no important truncations occur. I'm not sure what you mean by the "+1". This is the equation in my script.
Code:
$actual_glide := $Glide + ($Glide * $interval_cents / 1200 * ($Scaling - 100) / 100)

This reduces to my form when you factor out $Glide and remove the scaling (I don't mean your Scaling function, I mean the precision scaling). I realize that we need to use scaling to preserve precision when using integer arithmetic, but, I thought it would be easier to talk about if we pretended we had floating point math available. But if math isn't your 'cup of tea', perhaps you could just tell me in words how you wanted the actual_glide time to depend on the glide interval. In your written description of the Scaling knob for example, you say that:

Scaling is the amount that the glide time increases over an octave. If it is set to 2 then every octave interval's glide time is twice the previous one.

But, strictly speaking, this isn't what's coded. For instance, with Scaling set to max, the value of actual_glide is: G + G*(Int/12)*2 = G*(1 + Int/6). For a one-octave interval actual_glide = 3*G, for a 2-octave interval actual_glide = 5*G, then 7*G, etc. When Int = 0, glide time is still G, again because of the +1 in the expression G*(Int/6 + 1).

What all this boils down to in words is that with Scaling at minimum, actual_glide time is a minimum of G and increases linearly by an amount G per octave of pitch interval, ie 2G, 3G, 4G, for one, two, or 3 octave intervals. If we drew it as a curve, it would be a straight line sloping upward at G per octave, and would strike the Y-axis at G. With Scaling set to max, the curve would again be a straight line but sloping upward at 2G per octave but again striking the Y-axis at G. I can understand the slope of the curve, but, why do you want it to minimize at G? Wouldn't it be more logical to have G represent the glide time per octave or something like that? It only does so now in a funny sort of way, which I suspect was intentional and that's what I'm trying to get a handle on.

Perhaps if you could just state in words how you wanted actual_glide to depend on the glide interval it would ignite a light bulb in my headhttp://www.northernsounds.com/forum/images/smilies/redface.gif .

Bob

PS I tried leaving out the extra fade_out and I didn't notice any difference in performance. That's what prompted the question. I figured this might be one of 'those KSP problems' (like the stuck notes) that you were working around. I'll try leaving it out but if there's a pothole to fall in, you can be sure I'll fall into it.

fizbin

08-27-2005, 10:49 PM

I guess strictly speaking it isn't always twice the glide length of the previous octave. One octave interval is twice that of no interval. A two octave interval is 3 times that of no interval which is not twice the value of the one octave interval. I see what you're saying, but I'm not sure if it will be all that musical to actually increase scaling so that each interval has truly twice the glide time of the previous one. You'd have your exponential curve then rather than the straight line, but it's difficult to know ahead of time if that would sound more natural. You can give it a shot if you want and see :-)

Regarding leaving out the extra fade_out: Did you turn off the first note so you could tell for sure that the subsequent fade_in was then occurring correctly? I'd have to revisit it, but I know that I did add it for a good reason at the time. Maybe the scripting engine has changed sightly since then. I don't know for sure.

fizbin

Big Bob

08-27-2005, 11:27 PM

I see what you're saying, but I'm not sure if it will be all that musical to actually increase scaling so that each interval has truly twice the glide time of the previous one. You'd have your logarithmic curve then rather than the straight line, but it's difficult to know ahead of time if that would sound more natural. You can give it a shot if you want and see :-)

I hear you! I'll do some experiments later on to see what pops up, but, I was interested in knowing if you had some special reason for implementing it the way you did (other than it sounded about right musically, which it does).

Regarding leaving out the extra fade_out: Did you turn off the first note so you could tell for sure that the subsequent fade_in was then occurring correctly? I'd have to revisit it, but I know that I did add it for a good reason at the time. Maybe the scripting engine has changed sightly since then. I don't know for sure.

With this, I guess more experimentation with the KSP is in order before concluding that the first fade_out isn't needed. This sort of thing isn't well documented and of course may easily change in the next revision of K2.

Just for your collection, here's some KSP trivia that I've uncovered so far.

1. If you set the 3rd parameter to 1 for a fade_out, and, the fade finishes before the corresponding key is lifted, not only does the voice stop but, apparently the event is also retired (without producing any release callback). Later when the key is actually lifted, nothing further happens. This can result in a stuck key display.

2. Because of the above, any derivative notes will be left hanging also. For example:

fade_out($EVENT_ID,2000000,1)
play_note($EVENT_NOTE + 7,$EVENT_VELOCITY,0,-1)

This will leave the 5th hanging if you hold the initiating key down for more than 2 seconds. Note that if the 3rd parameter is set to zero, although the sample continues silently, it and the derivative note will end with release callbacks when the parent key is lifted.

3. A fade_in following a fade_out (for the same event) behaves as if the fade_out didn't exist (unless of course a pause is inserted in between).

One other thing I've been pondering is the conditional elimination of the play_note call (when the user is using the DFD mode and/or if he sets the $Start value to zero). If we just tune the originating note, we can probably avoid the hung note problem associated with play_note (I wish they would get that fixed). The code could be altered so that when Start is non-zero, the parent note is ignored and the play_note child is substituted. But, when Start is set to zero, the original note is used without generating a child note. If you see anything wrong with this idea, let me know.

DoctorZeus

08-28-2005, 05:44 AM

Oh, that's a shame. I guess that means that the method Theo described, using several instances at different levels with different glides, to get a more realistic sound cannot be condensed into a single instrument...

... which means there is no easy way to save a portamento patch for easy opening - you'd have to create it every time.

Oh well.

Thanks.

I don't think so. While you can enable and disable groups by script. You don't really get a handle to a group in the script to manipulate it seperately. You play a note and get a handle on a note, which can include layers from different groups, but you can only affect the note and then all groups played by that note as a whole. I'd love to know if I'm wrong.

fizbin

Theodor

08-28-2005, 09:54 AM

Hey Doctor Zeus,

You can always save it as a multi and then load the whole thing. Just asign all the patches of the multi to the same channel. I've bugged NI a few times about making the Multis not replace all the other instruments so you can load them anytime.

For the glide demos I used 1 patch loaded in DFD (The normal one) and the 3 other ones that use the script are loaded in Sampler mode so you can set the Sample start time as well. So even if you could have everything in a single patch, you woul'dnt be able to load half groups in DFD and half in Sampler modes.

By the way Fizbin, is there a small fade in, everytime a new sample glides? If yes, could that be assigned to a knob? (It could be just the ADSR though)

Thanks guys, these are great times to be a musician!

Oh, another BTW: Loading the same samples in Sampler Mode multiple times does not take more memory, just the first time loads in. So have no worries there Doctor Zeus

pmwaring

08-28-2005, 10:15 AM

Wow, what a nice script. I have been wrestling with getting some nice slides into some of the middle eastern instruments in EWQL Ra.

I have used Fizbin's script to add some nice slides to the sitar, string section and fiddle in this piece.

Desert Song (http://www.paulwaring.co.uk/docs/music/Desert.mp3)

DoctorZeus

08-28-2005, 10:23 AM

Thanks, Theo. Yeah, I know you can save a multi but then, as you say, you cannot load it into an existing multi. We really need to be able to load a multi (or some other "container" of several instruments) into an existing multi.

I'll try that "sampler" mode trick - I hadn't done that!

Thanks. :)

Hey Doctor Zeus,

You can always save it as a multi and then load the whole thing. Just asign all the patches of the multi to the same channel. I've bugged NI a few times about making the Multis not replace all the other instruments so you can load them anytime.

For the glide demos I used 1 patch loaded in DFD (The normal one) and the 3 other ones that use the script are loaded in Sampler mode so you can set the Sample start time as well. So even if you could have everything in a single patch, you woul'dnt be able to load half groups in DFD and half in Sampler modes.

By the way Fizbin, is there a small fade in, everytime a new sample glides? If yes, could that be assigned to a knob? (It could be just the ADSR though)

Thanks guys, these are great times to be a musician!

Oh, another BTW: Loading the same samples in Sampler Mode multiple times does not take more memory, just the first time loads in. So have no worries there Doctor Zeus

Theodor

08-28-2005, 03:35 PM

I really liked the desert song, cool stuff man :cool:

mixolydian

08-28-2005, 05:09 PM

Indeed, Paul you're rocking the desert! Really cool and I like it too. Have you used Fizbin's script for your overdrive guitar too... :D *Just kidding*

BTW: what guitar setup did you're using? Sounds pretty good. I've bought the GNX 3 one year ago and I'm happy with it.

Regards

pmwaring

08-28-2005, 08:08 PM

BTW: what guitar setup did you're using? Sounds pretty good.

It's Native Instruments Guitar Rig. :)

mixolydian

08-29-2005, 10:16 AM

Thanks. Have to check this out.

potatobug

08-30-2005, 01:27 AM

Nice work fizbin. Thanks!!!

mixolydian

08-30-2005, 10:08 AM

Hi there,

one question please, hope I don't have overlooked something: I like to have more than one portamento speed in one project e.g. with the violins. What is to do: load the same violin patch two or more times and add the script to every patch I like to have a different portamento speed?

(And loading the same patch two or more times makes no difference in RAM or CPU saturation? That would be great.)

Thanks in advance.

Best Regards

fizbin

08-30-2005, 01:26 PM

Yes, you can load it twice. It will make no difference in RAM as it does not load the samples twice. It may take a tiny bit more CPU power. You should try it for yourself and find out.

Best,
fizibn

mixolydian

08-30-2005, 08:09 PM

O.k., thank you. And thanks again for your script...! :)

BTW: Are you a qualified programmer or is that selfteaching knowledge? I'd like to do some PHP programming (the code looks similar) in the past but it is too heavy for me. Worse luck! Object oriented programming is nothing to learn on the fly... :o

Best regards

fizbin

08-30-2005, 10:46 PM

BTW: Are you a qualified programmer or is that selfteaching knowledge?

Not really and certainly not in PHP, but I do work in IT, so scripting is part of everyday life.

fizbin

pmwaring

09-02-2005, 08:05 AM

I have been experimenting with the SampleTekk's Renaissance Flutes in Kontakt 2 using Fizbin's portamento/glide script. I have been able to get some really otherworldy ethereal/vocal sounds. Not very useful if you want a pure recorder sound, but very cool if you want something a little different. ;)

Here's a subtle little demo of the script in action. Here the slides makes the recorder sound a little oriental and/or Irish!!!

Renaissance Flute & Glide Script Demo (http://www.paulwaring.co.uk/docs/music/Glide.mp3)

pmwaring

09-09-2005, 08:42 AM

Actually bud, most of those slides sound perfectly natural. If you're a good recorder player you can play the majority of the pitch bends yah wrote. ;)

Cool! The script gives the library a whole new authentic articulation :cool:

I must admit that I'm not that familiar with the full range of techniques that are available to the recorder player. A friend of mine is an excellent recorder player, perhaps I should ask her to demonstrate all the playing techniques that are available to her.

mixolydian

09-09-2005, 10:03 AM

Hi,

can anybody tell me what "recorder player" means? Is this to record in real time to the opposite of midi notation (piano roll) and score? :confused:

sfiks

09-09-2005, 12:29 PM

Hi,

can anybody tell me what "recorder player" means?
Read about recorder player here (http://www.recorderhomepage.net/players.html)

mixolydian

09-09-2005, 03:19 PM

Thanks. After reading something on this side I was totaly confused, because there's no description about "recorder". I tried an online translation and now I know that recorder means "Blockflöte" (flute). I'm stupid! :p

mixolydian

09-13-2005, 10:37 PM

Hi,

a new song featured by fizbins portamento script. But remember: I'm not a composer, just a rock musician.

http://northernsounds.com/forum/showthread.php?t=38130

Regards

Theodor

09-16-2005, 06:12 AM

Hi Fizbin, thanks again for your wonderful script. You're the man.

Two questions :)

In a glide from C to G: C glides towards G.. somewhere in the middle G at a lower pitch comes in and then glides towards G natural?

If yes, could there be a knob that allows you to have more notes in between?
Like, glide from C , to D, to E, and then to G (the knob would allow you to chose 1, 2, 3 etc intervals at which the glide will pass through until it gets to the target note).

Do you think that would be overkill? I'm just thinking it might make the glide more realistic at bigger intervals.

And second question, quoting myself: "Just our of curiosity, is there any possibility of seeing a script that will re-pitch the same sample instead of gliding towards a newly played sampled?"

Any news on that ? hehehe (sorry to bug you mate :) )

Cheers!

Theodor

09-16-2005, 06:34 AM

One more thing:

Any chance of controlling Glide Time with a Midi CC ?

Cheers

Big Bob

09-16-2005, 01:24 PM

In a glide from C to G: C glides towards G.. somewhere in the middle G at a lower pitch comes in and then glides towards G natural?

If yes, could there be a knob that allows you to have more notes in between?
Like, glide from C , to D, to E, and then to G (the knob would allow you to chose 1, 2, 3 etc intervals at which the glide will pass through until it gets to the target note).
Hey Theo,

I've been using 'fizbending' for some fairly realistic trombone glissandos and I think you can achieve what you want by simply playing more overlapping notes in between instead of simply holding down C and then hitting G, try playing a chromatic run with overlapping notes.

Regarding using a CC, I've started working on some embellishments to Jay's script (including CC control) but things have been moving slowly because I've been having more computer problems (which may now finally be fixed, I hope).

Bob

Theodor

09-17-2005, 03:38 AM

Hi Wonderful Bob, thanks for the wonderful idea.

Chromatic glide could still come in handy i believe because for example i use 2 french horns together (a horn section playing normal, and a french solo playing the glide), so if you put notes in between, the attacks of the one without the glide will be heard too much.

But still this helps a lot!

I hope you get your pc up and running soon :)

Cheers,

Big Bob

09-18-2005, 02:00 PM

Chromatic glide could still come in handy i believe because for example i use 2 french horns together (a horn section playing normal, and a french solo playing the glide), so if you put notes in between, the attacks of the one without the glide will be heard too much.
Hi Theo,

I'm not sure I understand the situation you described. Why do the extra notes on the solo instrument affect the horn section? Are you doing both with with fizbending enabled? Why not just disable fizbending for the horn section?, etc, etc. I must admit that I don't do much in the way of synthesizing multiple instruments at the same time. I usually mutitrack one instrument at a time to my VS2000 and do all the mixing there. As a result, I don't usually have to contend with multiple instruments at one time in K2. I can get away with this because I don't do too many large orchestrations and I mostly record acoustic instruments.

If you can elaborate on the problem in a way I can understand, I might be able to provide some additional control functions that will help the situation (when I put the finishing touches on my enhanced fizbending script).

Theodor

09-18-2005, 05:13 PM

Hi Bob,

I have a normal patch which has a French horn with no fizbending. Assigned to the same output channel i have another solo french with fizbending at lower volume so they are both playing at the same time.

If i do a E4 to F4 (or even F#4) it sounds very nice, but if i do an E3 to A3 or B3, the sample stretching gets a little bit too obvious. If i insert notes in between, it becomes too obvious for the non-fizbending horn that i inserted notes there.

So i was thinking, if you want to go from E3 to A3 it would pass through G3 first for example and then stretch G3 towards A3. That would happen only on the fizbending horn (for a natural glide) while the normal horn would not be affected. Something like a chain glide.

Perhaps this is not even worth the trouble, what do you think Master Bob?

Thanks

fizbin

09-18-2005, 08:03 PM

I know what you're saying about the wider interval bends - you hear a bit of a zipping sound. I'm not sure that what you're suggesting would cure it, but it is definitely worth a try.

CC control of the glide time should be easy to implement. I'm sure Bob's all over it. I'm currently on vacation from all scripting but plan to return very soon. :-)

fizbin

Big Bob

09-18-2005, 09:39 PM

If i do a E4 to F4 (or even F#4) it sounds very nice, but if i do an E3 to A3 or B3, the sample stretching gets a little bit too obvious. If i insert notes in between, it becomes too obvious for the non-fizbending horn that i inserted notes there.

So i was thinking, if you want to go from E3 to A3 it would pass through G3 first for example and then stretch G3 towards A3. That would happen only on the fizbending horn (for a natural glide) while the normal horn would not be affected. Something like a chain glide.

Hi Theo,

I understand why you want the glide to use more samples (as requested in the 2nd paragraph above). But I'm still not sure why playing 'in-between' notes should give it any kind of different sound than it would have if these 'in-between' notes were being generated by the script. As long as each played note overlaps its predecessor, the script folds them in in the same way. Since Jay uses up to 4 simultaneously-sounding, crossfaded samples when the glide time is longer than the individual note intervals, isn't it just a matter of setting the glide time properly? When I do trombone glissandos, I use enough glide time to insure that the individual notes in-between cannot be heard.

Originally, when I first started using fizbending, I too was thinking that I would embellish it to automatically include the 'interior' samples. But, after playing with it a while, I decided that it might be better to simply provide realtime control of the glide time. When the glide time is just right, the 'in-between' notes cannot be discerned.

It may be a little more work to play the 'in-between' notes (than if the script provided them automatically), but the benefit is that it allows you more musical control of the glide's contour. Of course, once we have MIDI control of the glide time, we can actually change the glide time during the glide. This may provide the means for contouring and maybe the idea of automatic 'interior' samples can be revisited?

Now that my computer seems to be cooperating again, I'll try to put more heat on this project and, as soon as I get something put together, we can all torture it and make up wish lists. By then Jay may be back from his 'scripting vacation' http://www.northernsounds.com/forum/images/smilies/wink.gif and, after a few iterations and multiple revisions, we may be able to end up with something we all like.

Big Bob

09-22-2005, 02:49 PM

This post is just to let everyone know that my computer is finally healthy again and I'm hard at work on the 'next generation' of the fizbending script. I've run into a few KSP problems though. Most of them I have a work around for, but, the biggest problem that will affect fizbending is the 'slew-rate' limitation.

The KSP apparently 'picks up' MIDI output data in discrete chunks at a rate which may be too slow to handle smooth bending when the desired pitch-change rate is fast. This causes the sound to become stairstepped instead of smooth. I'm trying to fully characterize this 'slew-rate' limitation and determine the optimum strategy for obtaining the highest rate possible. But it may turn out that certain rapid glissandos, especially those that sweep over a large interval, may not be possible without noticeable stair-stepping. I'll post again when I get a better handle on it.

Bob

Rich Pell

09-24-2005, 12:13 PM

Just, careful not to hurt yourself Bob...:D Rich

Big Bob

09-24-2005, 07:07 PM

Just, careful not to hurt yourself Bob...http://www.northernsounds.com/forum/images/smilies/biggrin.gif Rich Huh? Is what I'm doing dangerous as well as tedious?:confused:

fizbin

09-25-2005, 01:33 AM

Rich Pell

09-25-2005, 11:45 AM

Hi Bob -
How's it going with that script?

I think Rich was just poking fun at your uninhibited use of the term "slew rate". Like maybe if you were slaying a lot of things on say a hunting trip in just a short amount of time, you would have a really good "slew rate".

;-)
fizbin

Percisley Fiz ;) . Just reminding you to practice good "Slew-rate scripting" and speading the love Big Bob:|: . I`m actually in a bit of awe that you guys know how to do all this stuff and i appreciate both your hard work..I dont know the 1st thing about how to script yet.:o Peace, Rich

Big Bob

09-25-2005, 03:00 PM

Hi Bob -
How's it going with that script?

Hi Jay,

It's starting to 'cook' now. My time has been divided between working on the design of this script and chasing down computer problems. Right now everything is working OK except for a series of 'infamous' hot-swapping problems. So as long as I power down each time I swap a drive, I can keep working, but I have to devote sometime in parallel to hunting down solutions to these remaining problems.

The script design is still in a state of flux, but, I think it will have two major modes of operation. One is glide mode, an enhanced form of your fizbending script, and the other is sort of a super pitch bender mode (using 'inside samples' for formant correction). Hopefully, I should start coding the beta in about a week.

I think Rich was just poking fun at your uninhibited use of the term "slew rate". Like maybe if you were slaying a lot of things on say a hunting trip in just a short amount of time, you would have a really good "slew rate".
It is quite funny when you think of it that way but in engineering, the term 'slew-rate' has nothing to do with shortening anyone's life ;-) In electronics, slew rate usually refers to something like the maximum output rise time of an amplifier, regardless of the input signal rise time. When the input signal rises too fast, the amplifier's output is said to be 'slew-rate' limited. But, then I assume you guys probably already knew that huh? So, go ahead and laugh at me if you want, but remember they laughed at Thomas Edison when he invented the electric company and Albert Einstein when he invented the wild hairdohttp://www.northernsounds.com/forum/images/smilies/tongue.gif .

synergy543

09-25-2005, 10:40 PM

In electronics, slew rate usually refers to something like the maximum output rise time of an amplifier, regardless of the input signal rise time. When the input signal rises too fast, the amplifier's output is said to be 'slew-rate' limited. But, then I assume you guys probably already knew that huh?Probably not. I know a bit about electronics and used to use that term quite liberally until I noticed people looking confused. Its not a common term.

We just need to speed up the slew-rate of everyone's vocabularly learning. Great script btw. Look forward to V2.0

Big Bob

09-26-2005, 01:21 AM

Probably not. I know a bit about electronics and used to use that term quite liberally until I noticed people looking confused. Its not a common term.

Actually I was just being facetious when I said But, then I assume you guys probably already knew that huh?

Now I also realize that few forum members will care one way or the other about the following. But, for the few of you that are interested in such historical trivia, I will elaborate a little further about 'slew rate'.

Before the mid 60's the term 'slew-rate' was rarely heard. But with the advent of digital circuitry, circuit designers had to start using devices in their most non-linear regions (ie near cutoff and near saturation). Small signal parameters which specified a device's behaviour in a small linear region, were almost totally inappropriate in digital circuit design. When integrated circuit Op Amps appeared on the scene, analog designers still wanted to know all the small-signal parameters, but, digital designers were interested in using Op Amps as comparators. In this usage the output of the amplifier would swing between the max positive rail and the max negative rail. These two extremes were used to represent a logical zero and one. Even in those early days, most everyone was interested in making things run as fast as possible so a natural question was: how fast can an Op Amp change its output from min to max?

It was around this point (circa 1968) that 'slew-rate' specs became common-place on data sheets. The reason that the term may have become relatively obscure again, is that most circuit designers began specializing in either analog or digital design (and only more rarely both). Pure analog designers had no interest in things like slew-rate because they tended to use devices in their linear, small signal range. Pure digital designers on the other hand mostly designed with logical building blocks like flip-flops and gates. Only the circuit designers that actually had to make digital building blocks from analog components needed to think about such things as 'slew-rate'. With integrated circuitry supplanting discrete component design more and more, most of these circuit designers that were 'bi-lingual' migrated to the semiconductor houses to join the IC design teams.

As for me personally, I've been using the term 'slew-rate' for more than 35 years now so it's simply an intrinsic part of my vocabulary. However, I will in the future try to remember that this is a musical forum and not an engineering forumhttp://www.northernsounds.com/forum/images/smilies/redface.gif . My sincere apologies for tossing around unfamiliar terminology.

PS It just occured to me that I probably just did it again with terms like 'flip-flop' and Op Amp, Oh well, next time ....I promise ;-).

synergy543

09-28-2005, 04:23 AM

PS It just occured to me that I probably just did it again with terms like 'flip-flop' and Op Amp, Oh well, next time ....I promise ;-).Well Bob, if you start talking RTL and Nixie bulbs they're goning to put you away!

We used to seek out Op-Amps with fast slew rates to use as replacements inside our mixers - back in the days when we had to put our "paws" inside the hardware to keep it working.

Big Bob

09-28-2005, 01:24 PM

Well Bob, if you start talking RTL and Nixie bulbs they're goning to put you away!

We used to seek out Op-Amps with fast slew rates to use as replacements inside our mixers - back in the days when we had to put our "paws" inside the hardware to keep it working Ah! Someone else remembers those good/bad ol' days of things like RTL (or how about Diode/Resistor Logic?). Dare I even speak of earlier times when electronics was all vacuum tubes and once in a while I used to 'roll my own' capacitors?

Things sure have changed (and mostly for the better, at least as far as technology is concerned). I also remember more recently (circa 1975) when Honeywell had a defense contract to 'digitize' the world. Apparently a forerunner of the military GPS system. To pull this off, they needed to setup a mind-boggling amount of disc storage for their data base. I remember attending an 'open house' tour of that project's development area. They pointed to a room just full of 'wash-machine-sized' disc drive units and very proudly stated that all together these units provided one gigabyte of data-base storage! Now you can hold hundreds of those 'rooms' in the palm of your hand.

But, enough of this nostalgia, I have work to do (like pitch-bender scripts and stuff).

God Bless

synergy543

09-28-2005, 07:26 PM

But, enough of this nostalgia, I have work to do (like pitch-bender scripts and stuff).

God BlessHere's for the wishlist:

I would like to be able assign the script to keyswitches to turn the glide on/off while I play. I think this would be extremely useful.

Or maybe it would be better to use a relay to switch? :rolleyes:

Big Bob

09-28-2005, 11:13 PM

Here's for the wishlist:

I would like to be able assign the script to keyswitches to turn the glide on/off while I play. I think this would be extremely useful.
Do you prefer a keyswitch or would a MIDI CC (acting as a switch) do just as well? When using the script in the Glide mode, we may end up with optional MIDI control of Glide Time and that same controller could possibly be used to de-activate the effect. Of course when operating in the Super Bender mode the effect is easily turned off by simply not using the CC assigned as the bend controller. In any case, I will keep your suggestion in mind and try to provide at least some means of disabling the effect in real time (as I did with my Ultra TKT script).

Or maybe it would be better to use a relay to switch? http://www.northernsounds.com/forum/images/smilies/rolleyes.gif

Very cute! But don't get me going againhttp://www.northernsounds.com/forum/images/smilies/tongue.gif .

synergy543

09-29-2005, 04:07 AM

Do you prefer a keyswitch or would a MIDI CC (acting as a switch) do just as well? As a switch, a MIDI CC would work as well as long as it was assignable (say to a footswitch) although personally I prefer a keyswitch because even with only 61 keys, there are always some I'm not playing so its easy find two notes I can assign. The keyword being "assign". Because the script can be used with so many sounds they will be in all different registers.

However you mention MIDI CC acting as a "switch" as opposed to variable. Why? If you had variable control over the glide amount with a MIDI CC this could let the user assign a wheel or foot pedal to adjust the amount of glide desired. This type of interactivity would make the script a very nice performance tool.

I can really see where Garritan is going by setting Aftertouch as a requirement for his new Stradivarius - we really need all the controllers (and tenacles) we can get. So, err....um...instead of digits, why don't you make it in HEX? :rolleyes:

Big Bob

09-29-2005, 02:36 PM

However you mention MIDI CC acting as a "switch" as opposed to variable. Why? If you had variable control over the glide amount with a MIDI CC this could let the user assign a wheel or foot pedal to adjust the amount of glide desired. This type of interactivity would make the script a very nice performance tool.
I fully intend to provide continous control where it might be desireable, I was merely suggesting that a CC can do both continous control and on/off functions. Maybe you could think of it as an old radio volume control which when turned fully counter-clockwise would turn power off. This is a crude example of a CC being used both ways.

Actually, this whole issue of how best to control this thing deserves a thread by itself. I've been concentrating on the 'kernal' (or 'engine' if you prefer) because it will ultimately be the limiting factor in what we can do with it (regardless of how cleverly we design the Human Interface). I'm very nearly done optimizing the design and implementation of the 'Bender Engine' and I think the next thing that I'll do will be to start a new thread. I'll begin with a full description of what the capabilities and limitations of the Bender Engine are; and then call for ideas on the best way to utilize the engine's capability.

I think it will be important to not jump into this with pre-conceived notions. Much of our current thinking is based upon older ideas that were tied to technology limitations. For example, I'm not at all sure we want this to be either a 'Glider' or a 'Bender' in the traditional sense. I think rather, we need to re-think why we want to glide or bend and see if there isn't a better way to accomplish our goals.

Well, let me try to 'finish' the Bender Engine and we'll take it from there. So watch for a new and thought-provoking thread coming to your neighborhood soon!

fizbin

09-29-2005, 02:47 PM

Another possible feature might be "velocity latch" where the velocity of the whole phrase is locked into the velocity of the first note. It might make live use of it easier in some cases.

fizbin

Big Bob

09-29-2005, 09:52 PM

Another possible feature might be "velocity latch" where the velocity of the whole phrase is locked into the velocity of the first note. It might make live use of it easier in some cases.

fizbin

Good suggestion Fiz, I was also thinking along those lines. But again, let's save this kind of stuff for the new thread. I'll defer the human interface design until after everyone has had a chance to chime in with what they think will make a Super Bender.

I'm nearly done optimizing the 'engine', so pretty soon now I'll be able to post the details of what it can and can't do and then we can all begin to talk about the best way to control it.

Bob

Big Bob

10-02-2005, 02:56 PM

Hi Guys,

I've more or less completed the R & D on the new Super Bender/Glider 'engine' and I'm planning to start coding it in a few days but, I need some input from potential users regarding Sampler versus DFD usage.

The new script engine has the ability to quite literally 'play in the cracks' of the keyboard with rather amazing realism. This gives it the potential to play very convincing glissandos, etc. For example, when 'sliding' from C to G, all samples available between C and G are utilized as they are 'passed through' by using equal-power (sine/cosine) crossfading. To obtain the smoothest sounding, large-interval glides, the 'inside notes' need to be started after their attack portion and then smoothly crossfaded in. This is relatively easy to do in Sampler mode (where all samples are in RAM) because the script can start a sample using an 'offset' parameter. However, this 'offset' parameter is not functional when the samples are played in DFD mode.

Simulating an 'offset start' in DFD mode involves starting the sample (in a muted state) earlier than it will be needed and then bringing up its volume when needed. Because we can't be sure when these 'inner' samples will be required (apart from the ability to predict the future), it becomes necessary to always start a lot of samples early. This raises polyphony requirements and, for non-looped samples, might also mean that for long glide phrases, some of the inner notes might 'run out of gas' before they're needed.

To make this engine as flexible as possible, my first inclination was to code it so it will deliver comparable performance in either Sampler or DFD mode. However, the DFD mode adds considerable complexity and if few users intend to use it, maybe I won't include it (at least initially).

To summarize, the script will perform it's best in Sampler mode. But, without a special DFD mode, if you use the script in DFD mode, you may notice a small amount of 'stair-stepping' for fast glissandos. On the other hand, if I provide a special DFD mode, the performance will be nearly on a par with that of the Sampler mode but it will come at the expense of increased polyphony and sample length requirements.

So how about 'chiming in' here with how you feel about the Sample/DFD mode tradeoffs from a user's point of view.

T. S.

10-02-2005, 03:31 PM

Hi Bob,

I use DFD mostly all the time but that doesn't mean I wouldn't use the Sample mode to use your script and get a more realistic and better sound.

THere are "work arounds" and I'm more than willing to use them for something like this.

Maybe down the road a DFD version can be implimented so I say go for the Sample Mode version first.

I'm excited, my friend, about what your doing. :)

T.S

fizbin

10-02-2005, 06:02 PM

Yeah Bob, if you can pull off what I think you're attempting you may have a good fake legato patch as well as a good portamento patch. If you set the glide time on the current script low enough, it starts to sound legato-ish, however we've heard what can happen with large intervals.

Very ambitious effort on your part to smooth out the transition between notes, especially in DFD mode.

fizbin

Rich Pell

10-02-2005, 07:38 PM

Diriger

10-02-2005, 08:55 PM

Hi, I'm really interested in the development of the script and I use DFD exclusively. Using a sampler-only script wouldn't be practical with all of the patches that are usually loaded.
Looking forward to seeing how this turns out.

Big Bob

10-02-2005, 08:57 PM

Thanks Tod, Jay, and Rich for your quick responses. I'll wait a little while for a few more opinions (if they occur) but, it's beginning to look like maybe I should do the first 'engine' sans DFD mode and then maybe add it later if it seems worthwhile. If I defer DFD mode support, it will certainly save a lot of time and allow me to get to the next phase a lot faster.

Yeah Bob, if you can pull off what I think you're attempting you may have a good fake legato patch as well as a good portamento patch. If you set the glide time on the current script low enough, it starts to sound legato-ish, however we've heard what can happen with large intervals.

Yes indeed Fiz, this is one of the many topics I think we should explore when I launch the new thread calling for ideas on how best to control this thing. As I indicated previously, my idea at this point is to implement the kernal in the most general and flexible way so that most all the specifics of control can be done at a higher level. So whether this thing is used as a Glider, a formant-corrected pitch shifter, a legato note connector or what have you, the kernal can remain the same.

My original interest in this was sparked when was fooling around with Jay's fizbending script and a trombone patch. I heard some things that I never heard before using a sampled trombone and pitch bending. I have previously not been able to synthesize a truly convincing slide trombone so when I do Dixieland, I have to resort to digging out my old trombone and puckering up my lips. But, as I was devloping this script and I started to include 'inside samples', I have been able to produce some of the most authentic slide trombone glissandos I have ever heard. When controlled properly, I'm hard pressed to tell the difference from the 'real thing'. So, I'm getting kind of enthusiastic about this project.

Bob

PS

Hi, I'm really interested in the development of the script and I use DFD exclusively. Using a sampler-only script wouldn't be practical with all of the patches that are usually loaded.
Looking forward to seeing how this turns out.
__________________
Jeremy David Sagala
www.jeremysagala.com (http://www.jeremysagala.com/)

Hi Jeremy,

I guess you slipped in while I was posting the above response to Tod, Jay, and Rich. Maybe it would help if I mention a few more specifics. If I code the 'Bender Engine' with no special DFD support, it will still work in DFD mode and the difference in performance is rather subtle. For example, a glissando over an interval of a fifth, begins to sound a little 'stairstepped' but usually it's not too noticeable unless the slide is very rapid. Also, consider that you are not likely to want to add 'Super Bender' effects to every instrument you'll be using and K2 does allow you to use Sampler or DFD mode on a group by group basis. In any case I appreciate your input and, I haven't closed the door yet on special support for DFD mode.

Bob

Martin Nadeau

10-03-2005, 04:04 AM

Hi,

First, thanks so much Jay and Bob for the script. I've downloaded and tried the current version, and I think it has a lot of potential. It's already excellent, but with what Bob seems to be doing with it now, I think it might be indispensable for anyone working in Kontakt 2.

To answer your question Bob, the very vast majority of instruments that I'll use the script with, I will use in DFD mode. This is a script that could be used on all legato brass instruments for example, and it just wouldn't make sense to load all my sustained brass patches in Sampler mode, as this would use way too much RAM. Same thing with strings. However, I do understand that it's easier for you to implement the special features in sampler mode (at least at first), and since you say that the script will still work quite well in DFD mode, I don't really see a problem. But in a perfect world, it would be great if you could implement the same features in DFD mode. :)

I know you're going to start a new thread soon, but I thought I'd offer a feature suggestion or two for the script. One thing I'd like to be able to do is control the volume level of the slide. As I said, I've been trying the script with brass instruments (french horns and trumpets) to simulate a legato transition between notes. To do this, you have to set the slide time very low, so that the slide is really fast. This works pretty well except that I always thought the slide was much too loud compared to how the real instruments would play. My solution has been to insert a low cc #11 value in my sequencer just at the beginning of the slide, and then reinsert the higher original value a few ticks later. This works really well and I've been able to achieve very convincing legato playing (of french horns in particular), except that I have to manually input the cc #11 values for each note in a legato phrase, which is not very practical at all. So, having the ability in the script to lower or raise the slide volume level would be reallly great. If I have time tomorrow, I may try to post an example of the french horns legato playing with the fizbender script.

Another feature I would like seems to be impossible to implement, if I understand the previous messages in this thread correctly. It would be great if the script could be applied only to certain groups of an instrument, and not to others. The main reason this would be needed, at least for me, is for instruments that have release triggers with the resonance of the hall (e.g. SAM brass or EWQLSO Gold). Right now, the script cuts the release trigger right at the end of the slide, when the next note begins. This really doesn't sound good, as the reverb tail of the hall gets cut abruptly. There are 2 solutions to this:

1- To not use release triggers at all, but this makes me very very sad. :(

2- To create instruments that consist of only the release trigger (without the fizbender script), which can be assigned to the same midi channel as the normal instrument. This works well, but is not very practical as it necessitates loading twice as many instruments. This can be a problem if, for example, a filter was assigned to the original instrument. Now, you have to assign a filter to both the normal instrument and the release trigger instrument. Twice the filters = twice the processing power, and I've noticed that Kontakt 2's filters are very processor hungry. So, I guess the real question here is: has anybody been on NI's case yet, so that they allow a away to for a script to work only on specific groups of an instrument? If not, I think we should start harassing them about this. :)

Anyway, keep up the good work Bob, and keep us posted on the developments.

synergy543

10-03-2005, 04:54 AM

Martin's suggestions are excellent and his observations on the volume are particularly intriguing and I agree with his point very much. I wonder though if one volume envelope would cover all situations? For example, during the course of a single performance, sometimes you might want a subtle effect with a strong volume envelope change (say for larger intervals); at other times you might want no volume change - essentially the way it is now (maybe for shorter intervals). I would think having the choice among several envelopes might be desirable so it would be great if the 'amount' of volume change were programmable. So maybe at a low MIDI CC there might be an extremely pronounced volume change but at a higher MIDI CC there would be almost none. This would also be a good place to add the MIDI CC 'switch' so at the lowest MIDI CC, the portamento is completely turned off.

One possible downside of the above is it could generate an excessive amount of MIDI data from this controller relative to the function. An alternative would be if you could assign a few consecutive MIDI notes to act as keyswitches where the lowest key would be portamento off and as you progressed upwards, the volume effect would go from 'strong volume envelope' to no-effect. However, a continuous MIDI controller might be more musically useful and worth the 'overhead' - unused controller steps could easily be thinned or deleted for sequencing.

Maybe a linear/exp envelope contour setting might also be useful? Maybe something like the velocity curvewhere the slope is adjustable?

Martin, forgive me if I'm distorting or misrepresenting your idea but just wanted to share these thoughts which came to mind after reading your interesting suggestion which put into words so well what I was feeling but couldn't quite place my finger on.

Big Bob

10-03-2005, 01:09 PM

Thanks for the input guys, but of course most of this will be better situated in the new thread.

I will however point out something about your wishlist ideas. Obviously, each of you have certain very specific things you're trying to do and of course you'd love to have a script that would automatically solve some of the problems attendant to what you're now doing by other means. This is a good thing because 'necessity is the mother of invention' and all that jazz. However, what I hope we will be able to accomplish when we get the new thread going is to reduce a lot of such 'wishlist' items to a much smaller set of basic tools that will make it easier to do these things but not necessarily do everything that everybody wants in a fully automatic way. I'm hoping we will not only express specific needs but also attempt to arrive at a more general set of control functions that can help with (but not necessarily totally automate) those needs.

For example, extracting one of Martin's needs:

It would be great if the script could be applied only to certain groups of an instrument, and not to others. The main reason this would be needed, at least for me, is for instruments that have release triggers with the resonance of the hall (e.g. SAM brass or EWQLSO Gold). Right now, the script cuts the release trigger right at the end of the slide, when the next note begins. This really doesn't sound good, as the reverb tail of the hall gets cut abruptly

Now I read that alongside one of Synergy543's wishes:
Here's for the wishlist:

I would like to be able assign the script to keyswitches to turn the glide on/off while I play. I think this would be extremely useful.

And, then I say to myself, wouldn't Synergy's requested enable/disable function also solve Martin's cut off tail problem? Yes, I realize that you would have to insert the control code in the sequence (or activate it with your nose or something in a live situation) and that of course is not fully automatic, but, it would get the job done.

The problem with fully automatic things that do very specific functions is that we end up with either a whole bunch of special scripts or one giant script that does so many things that it may become bewildering to use. One advantage of the multi-tiered approach to designing this script will be that others will be able to write new, special-purpose scripts by only altering the higher levels of the code. Since this script will be well documented and 'open source', we can expect others to take up the gauntlet. Think of it like creating a variety of 'skins' for the same 'innards'.
************************************************** ******

Now, returning to the main topic of 'to DFD or not to DFD', maybe a compromise is in order. Instead of starting out with no DFD support, I could provide some limited support that would endow DFD with comparable-quality glides but at the expense of more resources.

Since everyone is already familiar with how Jay's script works, I'll use it as a clarifying example. Let's refer to the function of Jay's script as a Glider. Once the first note is played, each subsequent 'connected note' that's played becomes the 'current note' to further bend from (if desired). When the last played note is released, the script 'resets'. Let's call this bunch of connected notes from the first played until the last one is released a 'Bend Phrase'. When using the new 'bender engine' as a Glider, in DFD mode it becomes necessary to specify (in some way) the maximum bend range before the first note is struck. The range would generally be considered to be the maximum interval (plus or minus) from the played note that you can bend. But suppose that you glide from C upward to G, sit there a while and then glide from G upward to the next G (an octave up). If this is all part of the same Bend Phrase, the initial bend range has to be specified as 19 semitones. This will require that 19 * 2 = 38 notes be silently started with the first note.

To reduce some of the polyphony demands, I was originally going to code the engine so that the initially specified range would always apply to the last played note of a bend phrase (rather than the first played note). To do this, each time a new note is played, some of the silent notes would be terminated and other new ones would start up. This would then allow the example 'bend phrase' to be played with a polyphony of 2 * 12 = 24 instead of 38 notes. Of course. But implementing this 'dynamic range' scheme is rather tricky and time consuming. If I leave this sort of thing out (at least initially) the script will be more resource hungry in the DFD mode, but, it will operate with comparable quality to that of the Sampler mode. This is the sort of 'compromise' I'm thinking of making.

synergy543

10-06-2005, 05:25 PM

Would there be a way for the script to select from two different samples?

For example, the first one can have a full attack and the second could have its start time and envelope adjusted to bypass the onset of the attack to create a smoother legato.

Big Bob

10-07-2005, 12:21 AM

Sure enough, the 'inside samples' could be played from a different, keyswitched group as an example. The only problem with this idea is that in order to use the script, you first have to edit the instrument to cooperatively provide the needed, late-start samples. It's something to think about though. Of course the best answer would be for NI to make the offset parameter work in the DFD mode, no?

Right now, I'm fighting some new KSP/K2 problems relating to DFD mode for the super bender engine. It could be a bug in my code, but, so far it looks more like under certain conditions (involving the simultaneous startup of lots of samples), the KSP causes K2 to sort of go bananas and drive the CPU usage meter to the peg even after all the active voices have gone to zero! It's a weird problem and it's driving me nuts! But then, no one ever said this was going to be easy;) .

Bob

Theodor

10-07-2005, 01:17 PM

Hello Bob,

I also work in DFD mostly but whenever i make a Fizbending patch i load them in Sampler mode.

Cheers,

synergy543

10-07-2005, 06:10 PM

I also work in DFD mostly but whenever i make a Fizbending patch i load them in Sampler mode.Why? I thought DVD was 'good'?

Big Bob

10-08-2005, 12:25 AM

Why? I thought DVD was 'good'?
Probably so he can use the sample-start offset parameter that doesn't work in DFD mode.

I'm just guessing of course, so let's wait for Theo to respond.

Bob

Theodor

10-08-2005, 01:59 AM

Probably so he can use the sample-start offset parameter that doesn't work in DFD mode.

I'm just guessing of course, so let's wait for Theo to respond.

Bob

That's exactly right Bob :- )

synergy543

10-08-2005, 03:02 AM

Thanks TK and BigBob.
OK...here's my stupid question of the day: :( :o

How do I change a Kontakt patch from DFD to sample?

Is this it?:
Instrument Options>DVD & Load>DFD Preload Buffer?
Set to zero

Or is it in the Kontakt 2 Options>DFD
Set to zero

Do I need to save and reload? :confused:

Diriger

10-08-2005, 10:06 AM

Big Bob

10-08-2005, 01:06 PM

Click the wrench button to expand the instrument, then look around the top left of the green section. Just to the left of the word 'Source' you'll see a button that will enable you to choose the mode.

Note that this works on a group by group basis. So be sure to use the Group Editor to select the group(s) first. If you want to run all instrument groups in Sample (or DVD) mode, first click the Edit All Groups button.

Bob

synergy543

10-08-2005, 08:42 PM

Hey thanks guys. You can tell who didn't RTFM? :cool:

So do I need to save and reload to put this in effect?

Diriger

10-08-2005, 09:20 PM

Note that this works on a group by group basis.

I didn't know that...thanks!

Theodor

10-09-2005, 03:33 AM

Hey thanks guys. You can tell who didn't RTFM? :cool:

So do I need to save and reload to put this in effect?

You just click on the "Sampler" mode and the samples should get reloaded that moment.

( And Btw, if you ever get clicks from some samples that are looped, load them in Sampler mode and they should stop clicking. )

synergy543

10-11-2005, 04:52 AM

Great that you guys are working on this - its exciting stuff!

I think the power of the scripting was overlooked when Kontakt 2 first came out and is now just being realized for the first time.

I find it interesting that VSL has legato scripts they won't release (until they find a copy protection) so there's no point in buying Opus until they do. Meanwhile you guys are working on an interesting paralell path that may democratize the "legato" - or at least hopefully make it useable with other libraries.

Big Bob

10-11-2005, 01:56 PM

Hey alx (is that pronounced like 'Alex'?), welcome to the glide and slide thread.

Thanks for posting a lot of thought-provoking ideas. But, as I read through your posting and ponder what's involved in doing some of these things, I'm forced to remember that 'accurately' and 'authentically' emulating real acoustic instruments is still a monumental challenge. I'm afraid we're not going to conquer all these frontiers with one or two 'magic bullets'. But, we can 'chip away' at it with a script or two here and there and keep adding tools to our arsenals. As more and more 'scripters' join in the fun, I hope we'll see lots of 'little' solutions for some of the problems we're attempting to deal with.

Bob, from what I've read of your posts it seems you have found a work around for this by using all the samples in between in an ongoing crossfade of the conjoining samples. Great work, so that problem's solved. Ignoring DFD problems for a minute and only talking of the sampler mode, how is the CPU load while using this form of gliding?

In Sampler Mode, not too bad since, for most of the time, only two samples are sounding at once. In DFD mode the load is much heavier. If you have a glide limit of +/- a fifth, 16 samples need to be running. I'm hopeful that NI will soon find some clever way to handle the sample offset parameter in DFD mode as well and thus eliminate the need to handle this mode so differently from the Sampler mode.

The sliding between notes must be at a lower volume than the sustain, to retain the subtlety. It immediately sounds fake if the volume of this nuance between notes is as high as the sustained notes. Perhaps have a dedicated group or groups for the slide? Seeing as it's not possible to address individual groups, maybe there needs to be a separate patch which is dedicated to the slide itself?

This will have to wait for the discussion in the new thread. The initial version of the script engine will simply glide, slide, or bend at the same volume as the first played note of a phrase (glider mode) or the reference note being bent (in super-bender mode). The option of volume contours during a glide or glissando needs to be hammered out in more detail and a reasonable method of controlling it needs to be specified. As to the emulation of 'section glides', I think (at least for the foreseeable future) this will have to continue to be done piecemeal. But, after all, real sections are made up of pieces also!

I had already started my own similar script to this when I found this thread.
I'm trying to make a realistic sounding fake legato, which will (with a bit of luck) end up sounding like VSL's and can be applied to pretty much any sample library.

We'll all be interested in seeing it when you get it done. This whole issue of legato playing is another very complex situation. Perfection is always hard to achieve, but, even a rudimentary solution can be worlds better than no solution. Along those lines, have you tried Bosone's little legato script?
http://www.northernsounds.com/forum/showthread.php?t=38597

It's not very fancy, but, it could definitely be useful in many situations.

Finally, since I've been kind of bogged down, a little progress report might be in order. I've finally finished the design and coding of the Pitch Control Engine, PCE and I'm working on the documentation package. I'm also going to write a demo 'front-end' script that will allow everyone to kind of 'play around' with the PCE to get a feel for its capabilities and limitations. The Good Lord willing, I should be able to get this thing done now in about a week or two. So, watch for the new thread to appear. In the meantime, keep the ideas coming guys.

Bob

alx

10-12-2005, 12:34 AM

Hey alx (is that pronounced like 'Alex'?), welcome to the glide and slide thread.

Thanks for posting a lot of thought-provoking ideas. But, as I read through your posting and ponder what's involved in doing some of these things, I'm forced to remember that 'accurately' and 'authentically' emulating real acoustic instruments is still a monumental challenge. I'm afraid we're not going to conquer all these frontiers with one or two 'magic bullets'. But, we can 'chip away' at it with a script or two here and there and keep adding tools to our arsenals. As more and more 'scripters' join in the fun, I hope we'll see lots of 'little' solutions for some of the problems we're attempting to deal with.

Yep, my name's Alex.

I agree with you there, Bob. This is not going to be easy at all. I've been doing a fair bit of research on legato lately, I'm quite the obsessive type. :) I'm very keen to conquer this, and I've made some recent discoveries and good progress. Given that what I'm working on is a bit different to what you're working on, I think in the end it will still be a good idea to "compare notes" and combine what we've done to make something really cool. At present, my research is going solely into the "brup" sound I mentioned yesterday. IMHO, emulating the pitch, tone, timbre and humanisation of this sound is the key to a realistic sounding legato. I'm happy to say that this is where I've made some progress, and although what I'm doing is bloody time consuming and I've got a long way to go, I'm keen to continue.

At present, I'm compiling a database (and this is only for 1 "18 violins" section patch!) which contains the different likely (within a range of cents) possible tones that each brup will create, depending on which note you're coming from and going to. It is also different for going up and down, and what dynamic it is played at. Other information I'll include for each of these 500 odd brups is whether it is a louder or softer volume, and how much slide should occur.

This is a lot of information to compile, and I'm doing it all by ear so there may be a couple of errors, although I'm being pretty picky and testing each one as I go - so I doubt it. The good part is that I'm used to this sort of thing having worked at a bank doing data entry for a few years :). The difference being that this time It's actually for a constructive, music inspiring purpose, as opposed to the end product determining whether or not Habib Ahkbazkhazhan from Lakemba can borrow $10,000 over 7 years to buy mag wheels and kit up his shmick mobile.

I still dont know how well this is going to work, or whether the same theory can be applied to violin section samples from other libraries, and I wont be able to tell until I've finished. After I've finished compiling this database, I'll write some pseudocode - Bob, do you mind if I run this by you? It's plain for me to see that you know a lot more about coding than I. :)

We'll all be interested in seeing it when you get it done. This whole issue of legato playing is another very complex situation. Perfection is always hard to achieve, but, even a rudimentary solution can be worlds better than no solution. Along those lines, have you tried Bosone's little legato script?

It's not very fancy, but, it could definitely be useful in many situations.

Nah, haven't tried it yet, will do later. Thanks for the heads up.

Finally, since I've been kind of bogged down, a little progress report might be in order. I've finally finished the design and coding of the Pitch Control Engine, PCE and I'm working on the documentation package. I'm also going to write a demo 'front-end' script that will allow everyone to kind of 'play around' with the PCE to get a feel for its capabilities and limitations. The Good Lord willing, I should be able to get this thing done now in about a week or two. So, watch for the new thread to appear. In the meantime, keep the ideas coming guys.

Bob

Good to hear you're making progress, it sounds like you've got a pretty decent script happening there, can't wait to check it out.

-Alex

Big Bob

10-12-2005, 02:55 PM

I still dont know how well this is going to work, or whether the same theory can be applied to violin section samples from other libraries, and I wont be able to tell until I've finished. After I've finished compiling this database, I'll write some pseudocode - Bob, do you mind if I run this by you? It's plain for me to see that you know a lot more about coding than I. http://www.northernsounds.com/forum/images/smilies/smile.gif
Hi Alex,

No I don't mind you running anything by me' because I'm very interested in all such as this. I think it's always a good idea to share your thoughts with others in a forum like this. And, keep in mind that there are several others who are also 'quite-capable' at scripting, so there is always a possiblility that someone will be able to lend some degree of help to you in that area.

But, each of us have a limited amount of time that we can spend on scripting projects, so I hope you don't just plan to collect a massive amount of data and then say -- 'Well here it is, now will somebody please write a script to utilize all this'. On the other hand, if you personally have reduced your reams of data to some, much simpler subset and, if you have tried to incorporate your ideas into some kind of algorithm in pseudo code or a flow chart or maybe an actual K2 script that you just can't quite seem to get working right, I'm sure that one of us will be able to at least point you in the right direction.

In any case, I wish you much success with your project and look forward to hearing more from you.

God Bless

Bob

fizbin

10-12-2005, 05:44 PM

Hi all -
Just thought I'd chime in and grab the 100th post in this thread. :-P

Later,
fizbin

Big Bob

10-13-2005, 01:53 AM

Hey fiz,

Congratulations for hitting lucky 100! I think you now win a refrigerator and a trip around the world, but, I don't know who you see to claim the prize:cool:

Bob

Big Bob

10-20-2005, 01:34 PM

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!:mad:

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, 02:56 PM

mixolydian

10-20-2005, 03:24 PM

Sorry to hear this.

Big Bob

10-20-2005, 09: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 patcheshttp://www.northernsounds.com/forum/images/smilies/rolleyes.gif .

Bob

synergy543

10-20-2005, 09: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, 11: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, 06: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, 02: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, 03: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:o

fizbin

10-21-2005, 03: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