# Simple LFO with reset button script



## mbietenholz (Mar 7, 2008)

Here's a small script - someone over on the NI forum wanted a LFO that can be reset (eg. at the start of the track) - turns out K2's LFOs can either be reset with every note, or never, but not, for example, at the start of your track. It's pretty simple - triangle only, the LFO signal just shows up as Midi CC 20, so to use it you modulate whatever you want to modulate by CC20. But I'll post it here in case its of use to anyone. (Sorry about the unseemly lack of indentation, got lost in tranlation to html).

--------begin script here----------------------
{generates a simple retriggerable triangle LFO; LFO signal appears as
midi controller 20; goes from 0 to 127}

on init

declare $first_note := 1
declare $lfo_val := 64 { start LFO at midpoint}
declare $updown := 1 { start LFO going up}
declare $use_CC := 20 { use this midi-CC number for LFO}

declare ui_knob $LFO_speed (1,128,1)
declare ui_button $Reset_Up
declare ui_button $Reset_Down
message("")
end on

on note
if ($first_note > 0)
{first note, start the LFO}
message("starting lfo")
$first_note := 0
while ($lfo_val >= 0) { always true }

{ just do a triangle lfo }
if ($updown = 1)
$lfo_val := $lfo_val + 1
if ($lfo_val >= 127) 
$updown := 0
end if
else
$lfo_val := $lfo_val - 1
if ($lfo_val <= 0)
$updown := 1
end if
end if {updown}
set_controller ($use_CC, $lfo_val) {export our LFO value via. midi CC}
wait(100000/$LFO_speed) {100000 controls range of LFO speeds}
message(" ") {clear message again after first wait}
end while
end if {first_note}
end on

on ui_control($Reset_Up) 
$lfo_val := 64
$updown := 1
$Reset_Up := 0
end on

on ui_control($Reset_Down)
$lfo_val := 64
$updown := ò:Š   s0ú:Š   s0û:Š   s0ü:


----------



## Thonex (Mar 7, 2008)

Hi there,

Thanks for posting this!!!! :D 

I'm not at my studio but I'll try it when I get a chance. It looks cool.

It shouldn't be too hard to add a square or pulse wave option to your script.

Since Big Bob wrote a math library with Sin, Col and Log, you could even do a sine wave.... but that would involve incorporating Big Bobs Sine module in your script.

Thanks for sharing.

Cheers,

T


----------



## mbietenholz (Mar 7, 2008)

Thonex @ Fri Mar 07 said:


> Hi there,
> 
> Thanks for posting this!!!! :D
> 
> ...



Square and pulse should be pretty easy. If you want sine, unless you need it to be really pure you can probably get away with the first couple of terms of a taylor series, ie. sin(x) ~ x - x**3/6 + x**5/120 - x**7/5040 (where x is in radians, and is in range +/-pi).


----------



## kotori (Mar 7, 2008)

mbietenholz @ Fri Mar 07 said:


> Square and pulse should be pretty easy. If you want sine, unless you need it to be really pure you can probably get away with the first couple of terms of a taylor series, ie. sin(x) ~ x - x**3/6 + x**5/120 - x**7/5040 (where x is in radians, and is in range +/-pi).



Using the Taylor series is a nice idea, but can be problematic with 32-bit integer arithmetics. For example in the expression "x**7/5040" the variable x cannot be much greater than 40 or one will get overflow problems, this assuming that one doesn't calculate x**7 first and then divides by 5040 - if one were to do that it wouldn't work at all. I'd say it's easier in practice to use lookup-tables.

Btw. your usage of the ** operator for exponentiation makes me wonder if you're a Python, Ruby or Perl programmer. 

Cheers,
Nils


----------



## Thonex (Mar 7, 2008)

mbietenholz @ Fri Mar 07 said:


> you can probably get away with the first couple of terms of a taylor series......



:shock: you are going way over my head :lol: 

To me, Taylor series is a series of guitars made by taylor :D 

http://www.taylorguitars.com/Guitars/Acoustic-Electric/


I hope Nils is right and you are a Perl or Python programmer... and even if you're not.... I hope you pull up a chair and keep on sharing your ideas here. There are some great programmers who come here and I think you'll find this to be the "hot spot" for KSP programming.

Cheers,

T


----------



## kotori (Mar 7, 2008)

Thonex @ Fri Mar 07 said:


> To me, Taylor series is a series of guitars made by taylor :D
> 
> http://www.taylorguitars.com/Guitars/Acoustic-Electric/


:lol: 
I was just struck by how completely differently one can associate things! :shock:


----------



## ComposerDude (Mar 7, 2008)

...and whether a STRING is "a series of characters" or a vibrating filament sold by Ernie Ball...


----------



## Big Bob (Mar 8, 2008)

> Using the Taylor series is a nice idea, but can be problematic with 32-bit integer arithmetics. For example in the expression "x**7/5040" the variable x cannot be much greater than 40 or one will get overflow problems, this assuming that one doesn't calculate x**7 first and then divides by 5040 - if one were to do that it wouldn't work at all. I'd say it's easier in practice to use lookup-tables.



This is why I think the CORDIC algorithm is so admirably well suited to the KSP. The CORDIC uses a combination of lookup table and iteration loop to provide some of the 'best of both worlds' for simple, fixed-point systems. Consider the following:

1. While the CORDIC doesn't converge as quickly as a Taylor series, it does nevertheless allow you obtain about one bit of precision for each iteration. Even though a series can converge more rapidly, as Nils has pointed out, it's hard to realize the right combination of precision and number range with only a fixed-point arithmetic package. The Taylor Series approach is better suited to floating-point number crunching. 

2. The iteration loop of the CORDIC requires only elementary operations (simple 'right shifts' and 'signed addition'. Thus, the calculations are well suited to fixed-point integer arithmetic and there are no 'headò;]   s^ï;]   s^ð;]   s^ñ;]   s^ò;]   s^ó;]   s^ô;^   s^õ;^   s^ö;^   s^÷;^   s^ø;^   s^ù;^   s^ú;^   s^û;^   s^ü;^   s^ý;^   s^þ;^   s^ÿ;^   s_ ;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_	;^   s_
;^   s_;^   s_;^   s_ ;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_;^   s_ ;^   s_!;^   s_";^   s_#;^   s_$;^   s_%;^   s_&;_   s_';_   s_(;_   s_);_   s_*;_   s_+;_   s_,;_   s_-;_   s_.;_   s_/;_   s_0;_   s_1;_   s_2;_   s_3;_   s_4;_   s_5;_   s_6;_   s_7;_   s_8;_   s_9;_   s_:;_   s_;;_   s_<;_   s_=;_   s_>;_   s_?;_   [email protected];_   s_A;_   s_B;_   s_C;_   s_D;_   s_E;_   s_F;_   s_G;_   s_H;_   s_I;_   s_J;_   s_K;_   s_L;_   s_M;_   s_N;_   s_O;_   s_P;_   s_Q;_   s_R;_   s_S;_   s_T;_   s_U;_   s_V;_   s_W;_   s_X;_   s_Y;_   s_Z;_   s_[;_   s_\;_   s_];_   s_^              ò;_   s_`;_   s_a;_   s_b;_   s_c;_   s_d;_   s_e;_   s_f;_   s_g;_   s_h;_   s_i;_   s_j;_   s_k;_   s_l;_   s_m;_   s_n;_   s_o;_   s_p;_   s_q;_   s_r;_   s_s;_   s_t;_   s_u;_   s_v;_   s_w;_   s_x;_   s_y;_   s_z;_   s_{;_   s_|;_   s_};_   s


----------



## mbietenholz (Mar 9, 2008)

Big Bob @ Sat Mar 08 said:


> This is why I think the CORDIC algorithm is so admirably well suited to the KSP. The CORDIC uses a combination of lookup table and iteration loop to provide some of the 'best of both worlds' for simple, fixed-point systems. Consider the following
> ...



I defer to your deeper knowledge! I'm not used to thinking in integers, and it gets me in trouble every now and again (akkk - why is 1/x always identically 0??? )



> Btw. your usage of the ** operator for exponentiation makes me wonder if you're a Python, Ruby or Perl programmer.
> 
> If memory serves me right (which it seldom does these days :( ), ** was used for exponentiation in both FORTRAN and ALGOL, two of the earliest scientific languages. How's that for a bit of trivia :lol:



Your memory is functioning on this one, its probably from Fortran that I have the habit of using ** for exponentiation, although I've used Perl too, and keep meaning to get into Python. In fact, I _still_ program in Fortran - yes in 2008 - for scientific number-crunching, Fortran can produce slightly faster executables than C, so its not as completely backward as you might think, although the main reason why a bunch of the software I use in my non-KSP life is in Fortran is that it works and no-one has taken on the task of rewriting it.


----------



## Big Bob (Mar 9, 2008)

> In fact, I still program in Fortran - yes in 2008 - for scientific number-crunching, Fortran can produce slightly faster executables than C, so its not as completely backward as you might think, although the main reason why a bunch of the software I use in my non-KSP life is in Fortran is that it works and no-one has taken on the task of rewriting it.



Hey, if it isn't broken, why fix it? :lol:


----------

