# Delay/LFO sync values



## Casey Edwards (Oct 30, 2014)

Hey guys! I'm having a bit of a hair-puller over here. So recently, I've learned of the joys of tempo changes while trying to use the "sync" features in Kontakt. Those fancy little note heads that replace the "ms" readout have been useless to me since I realized that as soon as you change the tempo, the value distribution also changes. Then, I found an almost miracle work-around here: http://www.native-instruments.com/f...cript-article-tutorial-and-delay-sync.212362/

Integrating this into my script was super easy once I wrapped my head around it and I love the idea of using these look-up tables. It was also expanded to cover the full 20-400bpm of Kontakt. The only problem is that these values are incorrect and I reached out to the creator of this to confirm that. Could anyone lead me into the correct direction for being able to find the correct values? This stuff is a bit over my head at the moment.

Oh, I also looked here, but if there's anything of use in here then it also went over my head: http://www.vi-control.net/forum/viewtopic.php?t=19903

Here is my test code if you're interested: http://pastebin.com/R1PgFiuu

Any and all help is appreciated and thanks in advance!


----------



## FrozenPlain (Oct 30, 2014)

Hey, fancy seeing you here! Just wanted to say that the values are only slightly incorrect, it seems that for the longer delay times (1/1, 1/2), the echoes sometimes hit marginally before the beat. The shorter delay times (1/4,/1/8 ) seem to be pretty much on point. Though obviously, this is not perfect when you're after absolute synchronisation.

I made the lookup table from interpolating from a set of the delay display values and their corresponding values. Because only 211 points were sampled, and because linear interpolating is not dead accurate, there is a slight margin of error.
Another factor is that the delay display values (for example 1k ms) can have multiple knob values – 750000 could show 1k but also 750500 as well.

To make it more accurate you could sample more values for a more accurate interpolation. The formula I used is in the excel document.

I could be wrong, but I think there is no easy way to deal with synchronisation. 
Here is another work-around that you could try: http://www.vi-control.net/forum/viewtopic.php?t=24531

p.s. Sorry for the crude code in the article.


----------



## Casey Edwards (Oct 30, 2014)

Hey there - thanks for chiming in. It could come in handy if anyone has specific questions about your math. My problem is that the 1/1 and 1/2 values are more than slightly off when I'm running tempos of 60-80bpm, which are still reasonable writing tempi. However, like you said, the faster ones were so close (if not directly spot on) that you couldn't tell. 

I've read that other thread as well, and there are some nice suggestions in there, but so far, this is my favorite solution. It's so simple and elegant and I'm really rooting for this one to pull through. If I understood the approach better of how to gather these values, I'd just do the work myself and post my findings. Alas, I'm still working on that part. You've gotten us 95% of the way there; now we just need that final bit to sell it.


----------



## Mike Greene (Oct 30, 2014)

My methodology (which I don’t claim to be better) is different. Rather than having multiple arrays where there's one array for each note-length value, I just deal in microseconds. Then in the script, I use the built in $DURATION_QUARTER variable, then do the math to compute how many microseconds of delay I need. For example, an 8th note would be $DURATION_QUARTER/2 microseconds. Or a sixteenth note triplet would be $DURATION_QUARTER/6 microseconds.

Now I just need to know what engine value will give me that number of microseconds. Obviously I don't want an array with a million elements (one element for each microsecond value,) so I make a preliminary array that has microsecond amounts. The first element in this array is 0 microseconds, the second element is 10016 microseconds, the third element is 10190 microseconds, the 4th is 10714 microseconds, and so on, all the way to the 513th element (the last element,) which is 6000000 microseconds (6 seconds, which is Kontakt’s maximum delay.) In case you’re wondering why the sudden jump from 0 to 10016 at the beginning of this array, it’s because Kontakt doesn’t really like delay values below 10000 microseconds.

Armed with this array, the first step in my script is to find which microsecond value in this array is closest to my desired delay value.

Then I have a second array, with 513 corresponding elements. The elements in this array are the Kontakt delay engine values that correspond to the microsecond values in the first array. It’s a one to one correspondence.

So the first element in this array is 0, since that’s the engine value for 0 microseconds. The second value is 195, since that’s the engine value that corresponds to 10016 microseconds,. The third element is 2244, since that corresponds to 10190 microseconds, the 4th element is 8257, since that corresponds to 10714 microseconds, and so on, all the way to the 513th element (the last element,) which is 1000000, which corresponds to 6000000 microseconds.

For extra accuracy, I also do an interpolation step, since my desired microsecond value is unlikely to be an exact element in my array. More likely that my desired microsecond amount will be _between_ two elements in my array, so I do the math to estimate exactly where. It’s just a straight linear interpolation, which is plenty of accuracy for my purposes.


----------



## JohnG (Oct 30, 2014)

I knew I should have gone to college.


----------



## Mike Marino (Oct 30, 2014)

> I knew I should have gone to college.



I was assured there'd be no math.


----------



## mk282 (Oct 31, 2014)

Everything needed is one array really... For delay times, some values at some BPMs are not possible (if you're covering a range of up to 1/1).

Now that "cat's out of the bag" regarding this lookup array thing, I might as well help you guys out with correct engine parameter values for delay times with BPMs from 20 to 400. 

http://pastebin.com/raw.php?i=k5BW3Dqn


How did I get the correct values? Now... that's an entirely different thing


----------



## Casey Edwards (Oct 31, 2014)

mk282 @ Fri Oct 31 said:


> Everything needed is one array really... For delay times, some values at some BPMs are not possible (if you're covering a range of up to 1/1).
> 
> Now that "cat's out of the bag" regarding this lookup array thing, I might as well help you guys out with correct engine parameter values for delay times with BPMs from 20 to 400.
> 
> ...



Thanks a lot for this! I'm going to try and decipher this the best I can. I think it will take longer than Arcane, though.


----------



## mk282 (Oct 31, 2014)

Surely wouldn't, it's all in there...


----------



## Casey Edwards (Oct 31, 2014)

You're totally right. Super easy once I went through and checked it all out. Thanks a million for this!!!

EDIT: Btw, I'd be interested to hear what you have to say about the newest Kontakt update in regards to colors. At first I thought it was just a simple color palette addition, but it changed the hue of some colors (Yellow looks light green now) and the Default is now CYAN instead of BLUE. This has totally sent my existing patches into a color frenzy and my OCD is flaring because of it...


----------



## Casey Edwards (Oct 31, 2014)

One last question: Is it a pipe dream to think we can apply this same look-up table approach to an LFO? I've looked up a lot of threads on the matter, and I believe the only solution I've read was one where you mentioned using group names and string comparisons.


----------



## mk282 (Nov 1, 2014)

Yeah, some colors were changed to match the hues on S-Series keyboards (and Maschine, which uses the same 16 colors).

We can use the same approach to LFOs, but there's a bug in Kontakt that prevents you to get the real engine parameter values (just try it, set LFO frequency to 500000, then get_engine_par right after that and see what you'll get!), so unfortunately you cannot have a lookup table with correct EPs... means things wouldn't sync as well.


----------

