# Scripting a Global Sine LFO?



## patchen (Apr 20, 2016)

Hi All.
So, considering the long standing bug where Kontakt's LFO's go out of phase between groups when the rate is changed (Grrr..) I'd like to look into scripting one. Essentially I'd like to create a global sine wave LFO for tremolo. Does anybody know if this is possible and how difficult it would be? I know just enough scripting to get by and sometimes to get myself in trouble but hopefully I could integrate something like this. 

I'm hoping some code that just cycles from 0 to 1mil and back again in sine like fashion would do the trick? Thanks in advance for your time!


----------



## willbedford (Apr 21, 2016)

The most efficient way is to use a lookup table for the waveform. You can generate one using another programming language, or use a tool like this http://www.daycounter.com/Calculators/Sine-Generator-Calculator.phtml.

For a monophonic LFO, you can use the listener to cycle through the array. For a polyphonic LFO, you can use a loop in the note callback.

Be aware that, since you can't access the audio buffer from the script, a scripted LFO will never be as efficient as Kontakt's built in ones.


----------



## Lindon (Apr 21, 2016)

Bob's Math library also has a sine calc function, but as Will says the look-up is most efficient. The major problem you end up with is the "grain size" for each step - too big and you hear the LFO "stepping" too small and the CPU starts to suffer...


----------



## willbedford (Apr 21, 2016)

Lindon said:


> Bob's Math library also has a sine calc function, but as Will says the look-up is most efficient. The major problem you end up with is the "grain size" for each step - too big and you hear the LFO "stepping" too small and the CPU starts to suffer...


If you use Bob's math library, I'd still recommend copying it to an array on init.

If you only need it to be monophonic (which I'm guessing you do since you want a tremolo effect) you could overcome the grain size problem by sending the LFO values via CC and using the modulator lag to smooth them over. I haven't done any tests, but I assume this will be more efficient since the lag is calculated in the audio buffer.


----------



## EvilDragon (Apr 21, 2016)

CC will be more efficient, yes.


----------



## patchen (Apr 21, 2016)

Wow, thanks so much guys! Looks like lookup table it is. I suspected I could somehow do it with Bob's math library but if it is less efficiant perhaps not such a good idea. Online sine table generator, I had no idea such magic existed!


----------



## Lindon (Apr 22, 2016)

Theres a triangle one too...

http://www.daycounter.com/Calculators/Triangle-Wave-Generator-Calculator.phtml


----------



## willbedford (Apr 22, 2016)

Lindon said:


> Theres a triangle one too...
> 
> http://www.daycounter.com/Calculators/Triangle-Wave-Generator-Calculator.phtml


Triangle's easy to do in the script though


----------



## patchen (Apr 22, 2016)

I think you guys have set me off on the right path, thanks! On that note, Midi CC does seem to be the only way to keep it from sounding 'grainy' without chomping CPU but using cc for the LFO causes Kontakt's midi status light to go bananas! So, do you fellas have any tips on how to trick it into not reacting to midi cc data created from within the script or do I just have to live with it? 

I'm using the 'on listener' callback to run a test triangle wave for the time being, seemed like the reasonable way to do it. Again, thanks for your many wizdoms!


----------



## Andrew Aversa (Apr 22, 2016)

A scripted LFO shouldn't use much CPU even with a pretty fast listener... nor should it sound choppy. In a current project we have a listener running at 5ms w/ scripted LFOs and each one is barely a 1-2% CPU uptick. You can limit it to only be in use when certain voices are on (or any voices at all). We're not using lookup tables either, which would potentially be even more efficient.

Try a 5ms (not 5 MICRO second, but MILLIsecond) listener and see how it sounds!


----------



## patchen (Apr 23, 2016)

Hmm, Thanks for that info Andrew, good to know. Plenty of testing and research to do...


----------

