K2 portamento/glide script

[DoctorZeus]

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]

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]

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.

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]

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]

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]

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]

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]

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 head .

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]

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]

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.