# Calling All Scripting Gurus



## Big Bob (May 8, 2008)

Any of you scripting wizards know of a way (secret or otherwise) for a script to change the name of a group? Be the first to answer this question and maybe you will win a refrigerator and a trip around the world (then again maybe you won't :wink: ).

God Bless,

Bob


----------



## mmosc (May 8, 2008)

Bob,

You are the scripting wizard :wink:


----------



## Thonex (May 8, 2008)

Sorry Bob,

I don't believe there is a way to do this via a script. I looked into this a long time ago... and unless they've added some new commands that I'm unaware of, it is not possible.

However, Translator from Chicken systems I believe does this.. but that doesn't help with regards to scripting. :? 

Sorry... I'm useless as usual.

Cheers,

T


----------



## Big Bob (May 8, 2008)

Oh Andrew my friend,

You are definitely not useless and I don't know what we would do without you :roll: 

And, Mike, thanks for the vote of confidence but as you can see from my post, there is a least *one* thing I don't know how to do :lol: . Of course I'm just kidding because there are *lots and lots *of things I don't know :oops: 

Actually, now that I think about it a little more, even if there was a set_group_name function, until the KSP is endowed with a few more string operation functions, it would still miss the mark of what I was going to try for. So, there you are, yet another dumb dumb thing I did. Maybe I should go sit in the corner for a while :lol: 

God Bless,

Bob


----------



## Big Bob (May 30, 2008)

Thonex @ Fri May 30 said:


> Bob,
> 
> In another thread you were talking about SIPS DFD vs Sampler mode. This got me thinking... I still think it's not possible, but it got me thinking (always a dangerous thing) :lol: .
> 
> ...



I don't know of any way that a script can do this, but, I'd be happy if there was a simple way to 'clone' a group and then chop off a fixed amount from the front of the samples in the clone group by something as simple as 'moving the flag' as you put it. I asked the question on a different thread (but it was never answered), is there some way to edit all of a group's zones in one operation or do we have to do it one sample zone at a time? 

God Bless,

Bob

PS I wish someone would step on that bug crawling around in your posts :lol:


----------



## Thonex (May 30, 2008)

Big Bob @ Fri May 30 said:


> is there some way to edit all of a group's zones in one operation or do we have to do it one sample zone at a time?



Unfortunately, you have to do it 1 by 1. This is the single most idiotic thing about K2... it's lack of bulk editing.

How easy would it be to select all zones and just type in "1200" in the Sample Start box so that all zones start 1200 samples into the file. And how easy would it be if we could type in "+450" or "-280" in the same fashion to add or subtract to the position of the selected zones' Sample Start. :roll:


----------



## KingIdiot (Jun 2, 2008)

I've built scripts in Quick Keys to do what you guys are asking about moving the sample start points to a specific value. It requires mouse location edits and very careful "placement" of zones in the mapping editor. But I got it working pretty nicely.

As for in the KSP language, I didnt see anything that would allow the changing of a group name. The group ID could probably be fakes with some string of variables


th idea of going to Sampler mode, using the offset, then back to DFD is intriguing, but Kontakt loads its buffers based on the "sample start" marker in the actual instrument, and that isnt altered with the offset in Sampler mode.

Heres a trick I'll see if anyone is interestdin trying. As I'm busy thinking up other scripts, and I see what you guys are trying to do.

This is an idea I had before I eventually gave way to learning the KSP language. I ahd an idea that it could be done, and in truth I experamented with it WITHOUT scripting with very mixed results, and didnt really get further into it because I realized that without learning scripting it just wasnt going to be accurate enough for my tastes. 

It looks like you guys are trying to move the sample start automatically to create new "legato" instruments "automatically"

what about creating/copying a group of samples, then when legato is "engaged" trigger this new group and add an EXTREME pitch bend for a few milliseconds to advance the sample forward. Thus dividing the time it takes to get to a particular place in a sample by whatever the pitch bend value is. This will wreak havoc on the DFD most likely, but with a big enough buffer it should be fine.

If you trigger this new note with the volume at 0 and the note off of the last note(s) delayed slightly, then fade in the new note at normal pitch, you'd get an offset start with minimal delay (depending on how far into the sample you want to start.

Its a throw away idea that I was really interested in programming and sharing, but to be honest, I've got bigger script ideas to fry.

let me know if you guys try something like this, or atleast with the concept. I'd be interested to see where someone would go with it.


----------



## Big Bob (Jun 2, 2008)

Hi KI,



> what about creating/copying a group of samples, then when legato is "engaged" trigger this new group and add an EXTREME pitch bend for a few milliseconds to advance the sample forward. Thus dividing the time it takes to get to a particular place in a sample by whatever the pitch bend value is. This will wreak havoc on the DFD most likely, but with a big enough buffer it should be fine.



That's an interesting idea but I doubt if K2 uses faster playback speed to achieve pitch shifting upward. I'd have to try an actual experiment to verify this but I'm reasonably sure that they change the pitch without altering the playback speed. If so, the big upward pitch bend won't get us to the desired offset any faster.

From reading your post, I also think you may have misunderstood what I was rambling about. SIPS 2 can now optionally play samples from a different set of groups for the 'inside notes' of legato phrases. So all we need to do to make DFD mode sound the same as Sampler mode is to clone the 'normal' group with a DFD-Edited group. The DFD-Edited group has all the same sample zones but the start point is advanced. I was simply lamenting that NI didn't provide a simple way to move the start flag for all the zones in a given group. Instead we need to move the flag for each zone one by one. 

I wasn't suggesting that we have the script flip between DFD and Sampler mode. I was merely suggesting that we could use Sampler mode to tweak the offset for the best sound and then once we knew what that offset was, we could then lop off that much from the front in the DFD group. If we do it by moving the flag with a cloned group, we don't have to have another whole set of samples stored. Of course, the DFD preload will have to be different for the offset group than the non-offset group which will increase the overall preload size but I don't think we can avoid that.

I also thought of using something like Macro Express to do these repetive zone edits in a sort of 'robotic' fashion, but to tell you the truth, it just bugs me to think that we should have to resort to something like that. If memory serves me correctly, I think Nils may have written a Python program a long time ago to do something like this also. But, I just think it's a shame NI doesn't provide a simple way to do this within K2/K3.

In any case, my ramblings were mostly meant to be 'tongue in cheek' humor. :lol: 

God Bless,

Bob


----------



## KingIdiot (Jun 3, 2008)

Actually the swapping from DFD to Sampler and back was thonex's suggestion, and I was referencing that 

the concept of an extreme pitch shift will allow for you to divide the time it takes to get to a specific point in the sample by whatever the shifted amount. playback speed is actually faster. Its realtime sample rate conversion, but thining of it as hitting "Fast Forward" on a tape machine. This isnt the same as "offsetting" the sample start point, but it may (actually it does) allow for a quick "skip ahead" over the "Attack" portion of samples. The amount of skip ahead allowed before the playability is severely comprimised may be sufficient enough for some instruments.

I get what you're doing with SIPS, with regards to duplicating a group and moving the start point of all the zones and Ive built a ton of LEgato instruments in Kontakt this way myself, its in fact what I did for alot of the old QL instruments and MOR when programming them, and the very reason I built Quick Keys Scripts to do it. It *IS* possible for NI to impliment a "copy to all zones" feature for sample start. I'm just surprised it hasnt made its way into the new versions!!

Good luck with SIPS2 I'm sure it'll be pretty awesome with all the work you're putting into it, and the fact that you're listening to actual users reactions and suggestions!

Its interesting, I should probably spend mor time with SIPS, because I've been working on my own legato scipt ideas with different variations. Truth be told, some ideas cross over into what I believe the SIPS legato technique is, only with a different sample pool and some general changes. However I have an idea that might work WITH SIPS that maybe I shold fiddle with in my instrument building and MIDI work. I'll try some ideas out this week and get back to you.


----------



## Big Bob (Jun 3, 2008)

Hi KI,



> I get what you're doing with SIPS, with regards to duplicating a group and moving the start point of all the zones and Ive built a ton of LEgato instruments in Kontakt this way myself,



Actually, the sample-start offset only contributes a minor part of the legato effect in SIPS but it does make a small difference if its left out. And, since the script-controllable sample-start offset only functions in Sampler Mode, when you run in DFD mode, the SIPS legato effect, while still qutie good, does lose a little. So this whole business of finding a way to get a sample-start offset in DFD mode is actually more like 'gilding the lily' rather than being a make or break issue.

However, I was intrigued by your pitch shift idea so this morning I ran a few tests and indeed you are right in that K2 does play the sample faster when the sample is pitched upward. So, I'll try to spend a little more time on this later today because it does have some promise.

But, in my preliminary tests this morning, I noticed that there seems to be an upper limit for the 'pitch up' of about 9 octaves. At 10 octaves, K2 seems to become 'unreliable'. For example, using the following test code, at 10 octaves up, playing a series of notes (about one or two per second), causes K2 to clip some of the notes whereas at 9 octaves up, this doesn't happen.

I need to do further testing, but, it may be that this idea will be limited to 'racing' through the 'front' of the sample at a speed not much greater than 9:1. However, this may be sufficient to still be useful so it may be worth further exploration.

*on init*
``*declare* ui_knob Pitch (0,100,1) 
``*declare* ui_knob Pause (100,100000,1)
*end on*

*on note*
``change_tune(EVENT_ID,1200000*Pitch,0)
``wait(Pause)
``change_tune(EVENT_ID,0,0)
*end on*

Ideas like this always sound a 'little off the wall' at first but, sometimes thinking 'outside the box' is just what is needed. Thanks again for your thoughts and suggestions. I'll keep you posted on where this goes.

God Bless,

Bob


----------



## Thonex (Jun 3, 2008)

KingIdiot @ Tue Jun 03 said:


> the concept of an extreme pitch shift will allow for you to divide the time it takes to get to a specific point in the sample by whatever the shifted amount. playback speed is actually faster. Its realtime sample rate conversion, but thinking of it as hitting "Fast Forward" on a tape machine.



Now that's a cool idea. I've never thought of that as a work-around for "sample start offsets" in DFD mode. So, make sure the note is Faded_out, do a massive huge change_tune (say 2 octave up) for a moment, bring the pitch down again and then do a fade_in on the note. This could be a very cool trick. But if creating patches from scratch, I usually just program the off-set manually.... 

Nice thinking outside the box King!! o-[][]-o 

Cheers,

T

*[edit -- as usual, Big Bob beats me to the punch and kudos :lol: ]*


----------



## Big Bob (Jun 3, 2008)

Hi KI and Andrew,

Unfortunately, after some further testing, I don't think the pitch-up thing will fly. :cry: The problem centers around poor time control. For example using the following test code and setting the Pitch-up to 8 octaves and the Pause time to 10 msecs, one would ideally expect that the first 80msec of the sample would be played in 10msec and then the rest of the sample would be played normally.

*on init*
``*declare* ui_knob Pitch (0,100,1)``_{ In Octaves }_
``*declare* ui_knob Pause (1,1000,1) _{ In msecs }_
``*declare* target_time
*end on*

*on note*
``change_tune(EVENT_ID,1200000*Pitch,0)
``target_time := 1000*Pause
``*while* NOTE_DURATION[EVENT_NOTE] < target_time
````wait(100)
``*end while*
``change_tune(EVENT_ID,0,0)
*end on*


I used a test sample that was just under 9 seconds long when played normally. With the script and the above settings, the sample would play for widely varying lengths from about 5 secs to 8 secs. Effectively this means that the 8 to 1 speed up interval 'wobbles' from about 125ms to 500ms approximately.

The problem will boil down to this. In order to simulate a sample-start offset of of say 100ms, the product of the speed-up factor and the pitch-up time must be 100ms +/- a few ms. The timing inaccuracy of K2's non pre-emptive multitasking is such that there really is no reliable way to produce accurate and highly-repeatable time delays. So the bigger the speed-up factor, the worse the 'wobble' becomes. If I set the pitchup to more than 10 octaves, with the pause still set at 10ms, most of the time the sample only plays the high-pitch blip (which apparently 'burns up' the whole 8+ second sample),

Several years back, when the change_vol() function was very noisy, I tried to use the fade in/out functions to simulate the change_vol() function. The idea was to alternate between very long fade times and very short fade times to simulate static control. This idea would have worked but it depended on precise time control. Since I was never able to get K2 to produces accurate and stable time control, I had to abandon the idea.

I'm afraid the ptichup thing is going to suffer the same fate. Too bad because it was a nice idea. Sorry :cry: 

God Bless,

Bob


----------



## KingIdiot (Jun 3, 2008)

Big Bob,

no nono , I think you misundestand. Believe me I KNOW theres alot more going on with SIPS, I just meant that ,in regards to what you mean about duplicating the group and building a new set that will help the legato part of SIPS work better for faster instruments, I get the concept of how that helps and what needs to be done.

I know that you've put alot into SIPS and that theres alot going on, I dont in anyway want you to think that its a minor feat at all. Its a pretty developed script that works for alot of instruments, and des more than "legato". Thats a feat! It takes a lotto make a script thats "generalized" for different instruments, that still works well!

I'm glad you got to try the idea out. As I said I built a few tests of this concept using Envelopes and pitch modulation that had some nice results, but was always a bit unpredictable. This was back in the Kontakt 1 days! I knew that when scripting came along that it was something that could be revisited, but I'd moved on to other ideas. If the idea helps/works out I'd love to hear some results , and if it goes into SIPS at somepoint I'd love to have my name hidden in the code somewhere 

*EDIT:* Just read your new post Bummer that it isnt working. Do you think it might be more predictable with a lower pitch up setting. Kontakt has always been very unreliable with extreme pitch settings in DFD, so I didnt even think 10+ octaves would be the Number to go for, but obviously the lower the pitch, the more time it will take to "race" through the sample, and the more chance it will affect playability. I guess it all comes down to balance and convenience. Id be interested to see if you revisit it.

Thonex, thanks for the Kudos!

and i you guys think that THIS is out of the box thinking,... you have no idea whats in my head then, and what I'm trying ot work on. Theres stuff thats beyond the realm of legato that is just plain...well Insane! 

This was "tame" and is a reason I through it out there.


----------



## Thonex (Jun 3, 2008)

Big Bob @ Tue Jun 03 said:


> Effectively this means that the 8 to 1 speed up interval 'wobbles' from about 125ms to 500ms approximately.



So.... where's the problem Bob??? :D What we have here is a *random* psuedo offset... this is a new *feature!!!!* :lol: 

On a more serious note, I wonder if the randomness is directly correlated to the amount of change_tune. Maybe there is a "breaking" point at which you get this random behavior but below that breaking point its consistent?

T


----------



## KingIdiot (Jun 3, 2008)

Wait Big bob... I jsut re read your post

I think you've got the concept of what happens with Pitch bend a little off. 

Pitchign up 8 octaves and pausing for 10ms will not = 80ms

The distance into the sample will be based on the sample rate of the sample

say 44.1k, played at normal pitch (only on the key that plays it at normal pitch) 

so 8 octaves up will be 41,000 X 8 = 328,000

Which then has to be multiplied by the pause point. Which is 10ms in this example. which since the 44.1k sample rate is rated at "per second" would equal:

328,000/1000 = 328(samples per millisecond) *10 = a 3280 sample offset. Which in milliseconds is 74 I think

So you should be in 74 ms and not 80ms

Now, again, this is at a note where the sample will be playing at standard pitch.

what I beleve is going on with the "wobbling" is that if you stretch one sample over different keys in the mapping editer, it is goin to play at different sample rates, making the math slightly different based on which key.

so one key up will be 44100 + (44100/12) or 41000 + 3417 = 44417

so the note played transposed one semitone up will play at 44417 samples per second

so at this point the math for the "offset" at 10ms would be

(44100 + 3417) * 8 = 380,136/100 = 3800 * 44.1 = 86ms

So overall the math to decipher the millisecond offset for ONE sample stratched accross multiple keys would be

Transposed upwards
[44,100 + ((44100/12)*x) ] * y = z

(z/100)/44.1

Trnsposed downwards

[44,000 - ((44100/12)*x) ] * y = z

(z/100)/44.1

where:
x = transposition in semi tones from the original note
y = pitch shift in UI knob

This is possibly where your "wobble" is coming from

excuse me if my math seems a little archaic and inneficient. Or even if its a little off. I really havent been sleeping much lately.

also

I failed algebra twice in highschool. I've always been pretty good with numbers, but school never found a way to keep me interested in them. If only they got me into sampling


----------



## Big Bob (Jun 3, 2008)

Hi Andrew,



> On a more serious note, I wonder if the randomness is directly correlated to the amount of change_tune. Maybe there is a "breaking" point at which you get this random behavior but below that breaking point its consistent?



Primarily the problem is lack of time control accuracy and repeatability. As the change_tune amount gets bigger, it just magnifies the 'effect' of the time 'wobble' because the amount of 'front-end' sample consumed is proportional to the product of the 'pitch-up' factor and the time factor. There may also be some other problems introduced when the pitchup is really high but even if that mechanism was perfect, without stable time control it will still render this unusable.

I fought this time control issue from every direction I could several years ago and concluded that you just can't rely on K2's timing in any sort of precise and repeatable way. And, I don't see any way of using this idea that doesn't depend on reasonably tight time control.

I have found that even the ENGINE_UPTIME clock gets locks out when the multitasking activity gets heavy. If K2 provided a high-priority, time-driven 'interrupt' that always 'gets through' no matter what code is executing, then we might have some hope of doing this kind of thing. Unfortunately, the only thing a script can do is try to rapidly poll some reasonably stable clock. K2 has two problems that make this process very imprecise. (1) there really is no stable clock and (2) the polling interval has to depend on the 'wait' function which is notoriously 'wobbly'.

Maybe someone else can find an ingenious way around this dilemma and if so, please let me know what it is. :roll: 

In the meantime, I had better get back to updating the SIPS 2 User's Guide. I probably shouldn't have gotten involved in this but I found the idea quite interesting 8) . So I guess it's back to the grindstone for me :lol: 

God Bless,

Bob


----------



## KingIdiot (Jun 3, 2008)

Anyway, my above post only makes any difference if you stretched the one sample accross the keyboard. If it was just one note over and over, it probably shouldnt have varied.


----------



## Big Bob (Jun 3, 2008)

KingIdiot @ Tue Jun 03 said:


> Anyway, my above post only makes any difference if you stretched the one sample accross the keyboard. If it was just one note over and over, it probably shouldnt have varied.



Whoops! Sometimes I feel like a real dummy. :oops: I was back to working on my Manual when it popped into my head that I was using 8 octaves of ptichup and thinking as though it was a factor of 8 speed up. Of course this is not true :oops: . 8 octaves is actually a factor of 2^8 or 256:1 speed up >8o 

So I came back to apologize for that error and lo and behold I see you have already dropped a post identifying my error. :oops: I'm going to have to go stand in the corner again :? 

I will quickly revisit the tests because things probably aren't as bad as I made them out to be. However, the amount of time wobble may still produce unacceptable performance but we shall see. Let me breeze through it again and get a better handle on it and I'll be back.

God Bless,

Bob


----------



## KingIdiot (Jun 3, 2008)

heh no worries Big B. you're workingon multiple things, its ok to overlook things, especially when youre noodling. I dont mean to take you away from SIPS2. I know people are waiting. I only noticed that it was an issue in this post and I had and idea ages ago about how to fix it.

its interesting, I actually originally came up with this concept with Gigastudio 2.5 I believe, but only implemented it in Kontakt because of the envelope and modulation mapping and control options. I almost built an outboard midi script for it in another app, when i realized I was just losing time on stuff I actually SHOULD be doing!!

so I know exactly how you feel


----------



## Big Bob (Jun 3, 2008)

Hi KI,

I'm sorry to report that the KSP still can't hack it :( 

Here's what I did this time.

I first constructed a 400Hz sine wave sample that ramped from zero to max linearly over a period of one second. After that the tone remains steady for 4 more seconds. I then constructed an instrument that used only this sample mapped to a single key. I also ran in Sampler mode just so we wouldn't have to worry about any problems that might be introduced by the DFD machinery.

Thus playing the key, provides an output that starts at zero and then linearly ramps up to 100% over a one second interval. I then used the magic script to apply a 6 octave (64:1) pitchup for 10 ms. I then played the ramp sample over and over and recorded the output waveform in my audio editor. By noting where (between 0 and 100%) the waveform starts rising from, I can easily calculate the equivalent sample-start offset.

If things would have worked perfectly, we could expect an offset of 640ms and all the recorded notes would have started their rampup at 64% of max. Unfortunately, the actual results had the rampup starting anywhere from 25% to about 75% which is equivalent to a sample-start offset from about 300ms to 700ms. Notice that the 'wobble' is not symetrical which probably means that the 10ms is mostly coming up short rather than long.

I tried several different ways of generating the 10 ms interval with the same or worse results. So, I'm afraid that the conclusion remains the same. Too bad because it's a great idea KI, but the KSP just can't execute it well enough :x .

Now, for sure I'm going to go back to my SIPS 2 Manual :lol: .

God Bless,

Bob


----------



## KingIdiot (Jun 3, 2008)

Bummer. Well great effort Bob!

I'm sorry I took yu away from teh manual for so long . I'm currently in my own legato synthesis land o I guess I'll go back to that.

It is too bad, that it jsut cant be tamed.


----------

