Liteon's JS plugins pack

[mr jkn]

Well, I´m ok - but I sure jumped out of the chair :-)
This happened when just loading it. Output showed +6000 db! Cool.
Maybe because I´m on the beta version of reaper (osx)?

[RokkD]

Hi liteon,

I just wanted to stop in here and thank you for all your hard work. I'm just lovin the rbjstereofilter, it is by far the best stereoizery type plugin I've ever used.

the best I say,

Thanks

--

[liteon]

Hello,

Time for a small update. :-)
I was working for a while on a couple of biquad peak filters. But the original algorithms of both were quite unstable so I had to make them to be, in a sense - less scientific and more practical tools. Both filters are done and I've decided to make a 3 band eq from them, with selectable filter type. (Well TYPEA could use some tweaks - regarding the BW)

So finally finished the implementation into JS yesterday.
This is the filter bank:


You can switch between TYPEA or TYPEB, as your preferred filter.
They behave almost the same in the midrange, but quite differently at the bottom and top end.

Here are some freq/magnitude plots. (sorry but Voxengo Span looks fuzzy even for average values) ;\

at scale/2 :



if you move the slider to 20000hz the band of TYPEB turns into shelf
(but you will have to tweak the BW for TYPEA to get the same shape)


generally TYPEB is better for modeling with close to shelf shapes but TYPEA can be used for sharper cuts.

different boost and cuts on the spectrum:


TYPEA does not perform very well at the low end with this BW but it can be adjusted.

You may not hear the difference between the two while switching and having subtle settings (+1...+3db), but believe me there are differences .
You can try this: Set low bandwidth (sharp q) add max boost (+18db) and sweep the top end with both filters. If I'm not mistaken TYPEB should sound slightly sharper.

Also I've tried to 'model' the saturation (mostly the concept) of an analog EQ. So there is a saturation control - it will add harmonics and noise floor to the original signal to soften and enrich the sound. When set to 0 it will be disabled and uses less CPU. You can consider this the 'analog' button of the EQ and it wont smash the signal that much even if you drive it to 100%.

Here is a sound demo. I did this on non-monitor speakers, so it may not the best sound demo ever. First track - dry/TYPEA, second track - dry/TYPEB.
Demo

Original filters from Stanley A. White and JAES papers.
----

I've also added a summed version (L+R) of the VUMeter.
Both the summed and the stereo version have a window to detect RMS now.



You can download the latest version of the pack from the first post.

enjoy
liteon

[Finnish]

I'm really looking forward to try this "update"! I'm on the road for a few days, but I'll certainly try these ASAP. Thanks!

[liteon]

Originally Posted by RokkD

Hi liteon,

I just wanted to stop in here and thank you for all your hard work. I'm just lovin the rbjstereofilter, it is by far the best stereoizery type plugin I've ever used.

the best I say,

Thanks

--

I'm glad you like Rokkd ^_^
It could use some oversampling for that drive control tho.

Originally Posted by Finnish

I'm really looking forward to try this "update"! I'm on the road for a few days, but I'll certainly try these ASAP. Thanks!

The new eq isn't exactly like the UAD stuff or the Waves API, but it can be useful. I've tried cleaning a old funk break today and it sounded much better with a couple of notches and a midrange boost.
And I doesn't null with some other eqs (ReaEQ for example) so guess it has something of its own. (Even if the concept of 'null-ing' is flawed on numerous levels :P )



BTW!!?

Does anyone know a freeware tool for measuring THD and phase shift. Spectrafoo is nice but it costs way too mucho.
I know about Christian Buddle's plugin analyzer, but its a VST host only.

Basically I'm looking for a quick way to measure these two of any JS plugin.

Cheers for any ideas

[mr jkn]

I find the eq great (on my pc-rig, on mac plugin still goes bzzz). One thing, when driving the saturation to 100% the noisefloor goes goes up quite a bit. This is normal I know, but I found other saturatiors (sic?) not generating as much background noise.

Keep up the good work!

[liteon]

Originally Posted by mr jkn

I find the eq great (on my pc-rig, on mac plugin still goes bzzz). One thing, when driving the saturation to 100% the noisefloor goes goes up quite a bit. This is normal I know, but I found other saturatiors (sic?) not generating as much background noise.

Keep up the good work!

cheers

Is the buzzz problem occurring with other JS filter/eq plugins on the mac?
If so maybe you should report this in the bug sub-forum.

If not:
Have you tried different sample rates (44.1, 48, 96..)
My filters seems to work fine with 44.1 / 48 over here.
But it doesn't make much sense, because I'm always using the 'srate' sysvar when calculating prewarp i.e. the filters are designed to work with different sample rates.

Yep the 'Floor Reduction' of the new EQ goes a little bit high (into the audible range) - approx -130db (1%) to -70db (100%)

But for example Voxengo Lampthruster (non-linear processing emulator) can go up to -18db. Also Lampthruster always generates filtered white noise, while this 3bandEQ only applies the 'FR' on input. I'm not sure if there are any standards that cover this. :-)

Please answer the above question if you want me to investigate further into the buzz problem.

liteon

[mr jkn]

Ok, now I look as I´m the fool. Opening a mix, threw on some of your fx - and it worked! No bzz-bonanza! I tried to replicate the problem by going from 44,1 khz to 96, sounded just fine. Am I loosing it?

Perhaps the bzz-thing happened in conjunction with other plugs, must investigate further. :-)

[labyrinth]

Liteon,

I must thank you for your great, most awesome plugs.

[griz lee]

The EQ is simply lovely. I like 'type B' best for what it's worth - it has a nice style at the top end.

Amazing job: i think you've removed some of the mythology from $$$ plugins with all this. I particularly like how it's unpretentious and extremely good quality at the same time.

I'm not getting any horrible mid-rangey fluffyness with your plugs that I can clearly hear in some commercial products (except perhaps Duende). That's quite an achievement.

[drillbit]

The RMS meter on the VUs is great, compares quite accurately to Voxengo's Elephants RMS meter (slightly different). Unfortunately I now think the needles are not moving as smoothly as before. I could be mistaken as I don't have the old ones any more.

Just an idea, maybe you could have it so when you click the VU it turns into an RMS meter.

I have to agree with a previous poster, your rbjstereofilter12db is a bit awesome. I see what it's doing and it's simple, but it really works well.

I showed your algorithms to my DSP guru friend Andy at Fxpansion and Cytomic. He noted that you were mainly implementing basic common filter code, but was impressed by all the work you had done. There were some problems with not oversampling on some things and there was something wrong with your pink noise plugin. Sorry to not get more details he's a busy guy at the moment with Synthsquad and his own Cytomic compressor coming out. He is a purist and has been doing this shit for years.

I think creating heaps of simpler filter plugins is a good way to learn and explore. There is definitely need for more good DSP programmers.

Did I mention the stereo filter rocks !!

cool

[liteon]

Hello drillbit and thanks for the support,

Originally Posted by drillbit

The RMS meter on the VUs is great, compares quite accurately to Voxengo's Elephants RMS meter (slightly different). Unfortunately I now think the needles are not moving as smoothly as before. I could be mistaken as I don't have the old ones any more.

Just an idea, maybe you could have it so when you click the VU it turns into an RMS meter.

I have to agree with a previous poster, your rbjstereofilter12db is a bit awesome. I see what it's doing and it's simple, but it really works well.

I've set the VU meter to default at 100ms. You should know that a VU meters by standard are at 300ms, so its even slower. This meter can also turn into a PPM (http://en.wikipedia.org/wiki/Peak_programme_meter) with faster response times (10ms). I though about adding another needle for the RMS meter, but since the average 'full' mix should be around -15db RMS, -12db RMS (Pure) the needle would be mostly in the far left. By adding it as digits, we can also monitor values below -20db RMS.

Originally Posted by drillbit

I showed your algorithms to my DSP guru friend Andy at Fxpansion and Cytomic. He noted that you were mainly implementing basic common filter code, but was impressed by all the work you had done. There were some problems with not oversampling on some things and there was something wrong with your pink noise plugin. Sorry to not get more details he's a busy guy at the moment with Synthsquad and his own Cytomic compressor coming out. He is a purist and has been doing this shit for years.

I think creating heaps of simpler filter plugins is a good way to learn and explore. There is definitely need for more good DSP programmers.

Did I mention the stereo filter rocks !!

cool

Thank you for the feedback.
Its always a good thing to get opinions from more experienced developers.
My interest in DSP was mostly inspired by JesuSonic as an awesome platform (around 3 months ago) and I do enjoy complex mathematics and programming very much.

Send my regards to your friend Andy for taking a look.
I agree 100% about the oversampling bit. And in general you should always oversample when applying waveshapers to prevent aliasing (if that's what he noticed). But oversampling is CPU hungry and optimization is a great issue that we have here. I still may add oversampling (not that difficult) to some of the fx one day but it will be 'off' by default.

I'm not familiar with FXPansion's products, but I don't really like such companies...I'm more with the 'quality over marketing' and the freebie bunch.
If every single plugin was open source, defining a 'simple' algorithm in the current, over-saturated market of plugins, may be as common as buying bread from the grocery store. But...people do hide behind binaries and fancy GUIs while selling and advertising products - which I don't tend to buy. But why do it for free in the first place? Most likely, with the simple idea to contribute.

liteon

[drillbit]

Here is one of the things Andy has been working full time on for the last two years:

http://www.synthsquad.com/

Working as a programmer is hard work. Andy has a family to support and needs to make a living. Maybe some of his work will filter down eventually like his original Vellocet filter code, but it is a bit naive to say that all plugin programming should be open source. Reaper is not open source and the main reason it's so affordable is that a genius like Justin was able to make a heap of money off a big corporation, thus he can pay the other programmers.

Your JS plugin development is great, but if that is what you did for a living I think you would have to charge for it. Some of the code in your plugins comes from people who worked for companies then eventually let their code be open. You might have even used some of Andy's.

[liteon]

I never said that everything should be open source...I also develop closed source commercial products on various programming languages, then sell them for a living. I also buy commercial products.

Some of the code in your plugins comes from people who worked for companies then eventually let their code be open. You might have even used some of Andy's.

Developers that work for companies aren't allowed to release any source code unless the company says so. More than 90% of the source posted online is by people who are in the linux community, students, teachers, geeks who are having fun while researching.

Now...If you trying to challenge my knowledge of things..
I accept! And I can prove you wrong in a matter of minutes.
I've build my first 9v analogue tone generator, when I was a kid so that I can participate in a 'Morz' learning class.
Bring it on ?

[andy_cytomic]

Originally Posted by liteon

I'm not familiar with FXPansion's products, but I don't really like such companies...I'm more with the 'quality over marketing' and the freebie bunch.
If every single plugin was open source, defining a 'simple' algorithm in the current, over-saturated market of plugins, may be as common as buying bread from the grocery store. But...people do hide behind binaries and fancy GUIs while selling and advertising products - which I don't tend to buy. But why do it for free in the first place? Most likely, with the simple idea to contribute.
liteon

I'm all about quality over marketing, I've been advising people to buy analog synths since they sound so good in the thread about the new synths I've just finished.

As for open source, I think the best approach is to write handy utility classes and make the open source / free. I've written a very handy lock free double buffer class specifically designed to get data between the dsp thread and the gui thread of plugins to speed them up http://www.cytomic.com/dsp/Nolock/, and I've also written an simple example filter and submitted it to music-dsp. Laurnet De Soras (Ohm Force) has written a great fft class and hiir resampler class http://ldesoras.free.fr/prod.html. What do you propose contributing?

Andrew Simper

[andy_cytomic]

I've also done a cross platform noise generation class, but I don't really consider that contributing anything to the community since all I did was get existing algorithms for white, pink and brown noise and make a c++ class out of them. http://www.vellocet.com/dsp/noise/VRand.html

Andrew Simper

[liteon]

Originally Posted by andy_cytomic

I'm all about quality over marketing, I've been advising people to buy analog synths since they sound so good in the thread about the new synths I've just finished.

As for open source, I think the best approach is to write handy utility classes and make the open source / free. I've written a very handy lock free double buffer class specifically designed to get data between the dsp thread and the gui thread of plugins to speed them up http://www.cytomic.com/dsp/Nolock/, and I've also written an simple example filter and submitted it to music-dsp. Laurnet De Soras (Ohm Force) has written a great fft class and hiir resampler class http://ldesoras.free.fr/prod.html. What do you propose contributing?

Andrew Simper

I haven't contributed much yet.

My handle at music-dsp is neolit123@gmail.com
I've ported that apple 12db (AU tutorial) filter from c++ to pseudo. After a while I guy from Finland contacted me with some questions and he wanted to use it on a DSP chip. He said that he didn't understand any other filters at music dsp - this one looked the most compact out of the bunch...
Some exponent curves that me and fellow cockos forum users calculated for frequency scales.

Some comments here and there and thats all. But hey, I've been doing it for 3 months. I've started studying some circuits recently some maybe I will come up with something new.

But C++ has never been my strongest language. I have a lot of experience with AS3 and some with JAVA for class based programming. Classes are the way to go for public use.

I can see your point with the given examples, that you and other fellow developers are contributing while working for companies. But are there any other examples. MDA, Bram and Christian don't work for plugin companies as far as I know. I'm not sure Alexey from Voxengo or the Nebula crew have released anything? Not to mention someone from Waves or UAD releasing code...

drillbit started the discussion and for a moment I though that you or him are impliing that I'm just porting stuff to JS. Well yeah mostly and I have admitted this, included references in all the JS plugins and commented if I've changed something in the algos here and there.

[liteon]

Originally Posted by andy_cytomic

I've also done a cross platform noise generation class, but I don't really consider that contributing anything to the community since all I did was get existing algorithms for white, pink and brown noise and make a c++ class out of them. http://www.vellocet.com/dsp/noise/VRand.html

Andrew Simper

What seems to be the problem with the pink noise generator in my pack btw. Is it the filters?
Again I took it from music-dsp. And its the most efficient for JS imho.

Edit: Wish you success with your projects and development! :-)

liteon

[andy_cytomic]

Originally Posted by liteon

What seems to be the problem with the pink noise generator in my pack btw. Is it the filters?
Again I took it from music-dsp. And its the most efficient for JS imho.

I can't remember sorry, but I'm sure you'll work it out. Implementing known algorithms and making tweaks to things is good to start with, but if you really want to progress I suggest deriving everything yourself from scratch since you get a much better understanding that way. Good luck with your dsp, and I look forward to you contributing something new and useful to the community, either as simple c++ or java, pascal, matlab, mathematica or any any other standard language

Andrew Simper

[andy_cytomic]

I could have been to do with not having equal power at all sample rates of the noise generated. My noise generation code for pink uses sample and hold so doesn't need this, but if you filter white noise you need to take care of it.

Andy

[liteon]

Originally Posted by andy_cytomic

I could have been to do with not having equal power at all sample rates of the noise generated. My noise generation code for pink uses sample and hold so doesn't need this, but if you filter white noise you need to take care of it.

Andy

Yes i thought of that exactly. If you have tested on higher sampler rates since the coefficients of the filters are precalculated and independant of the user's sample rate. I only have 44.1, 48 on my soundcard so I will have to design it differently.

Btw the lorenz attractor synth and the Vu meter are mostly mine from scratch. If we don't count the concept of Vu meters and the three determinant equations of the Lorenz system :-)

I will be posting step by step explanations about the VU meter soon. How I've approximated the scale (tried lagrange polynomial at first here lol) calculated x,y of the needle using radius etc.

liteon

[liteon]

http://www.firstpr.com.au/dsp/pink-noise/#Filtering

Andy's method with S&H, originates from Richard Voss if I'm not mistaken.
But I don't think this type of algorithm would be very efficient with JS.
Its supposed to be much more accurate compared to what I just did tho. (Same method used by RBJ and Paul Kellet which is from Sophocles Orfanidis).
Basically fine tuning a "pink filter" over white noise.

However both RBJ and Paul Kellet had posted coefficients for 44.1khz sample rate and they don't provide any info how they calculated them. I lol-ed at this from RBJ: "Don't give in to the Dark Side. Boycott intel and microsoft." x)

Here is what I did:

//trc - test rate coeff
trc = 1;
k0 = exp(-2*$pi*4752.456/srate*trc);
k1 = exp(-2*$pi*4030.961/srate*trc);
k2 = exp(-2*$pi*2784.711/srate*trc);
k3 = exp(-2*$pi*1538.461/srate*trc);
k4 = exp(-2*$pi*357.681/srate*trc);
k5 = exp(-2*$pi*100/srate*trc);
k6 = exp(-2*$pi*30/srate*trc);

I subtract one pole and add the other five + the original random byte.

whitel = rand(2)-1;
b0l = k0*whitel+k0*b0l;
b1l = k1*whitel+k1*b1l;
b2l = k2*whitel+k2*b2l;
b3l = k3*whitel+k3*b3l;
b4l = k4*whitel+k4*b4l;
b5l = k5*whitel+k5*b5l;
b6l = k6*whitel+k6*b6l;
pinkl = (b0l+b1l+b2l+b3l+b4l+b5l+whitel-b6l);

This is obviously less efficient than the previous version by Paul Kallet fro this JS fx but it works well on higher sample rates.

Here are some comparisons with a "pinkfilter" from a product X...

at 48khz


at 192khz (calculated output)

(both degrade slightly)

If someone has 192khz sound card, can you give this a go, before I upload in the pack. Just run the the attached JS FX and a spectrum analyzer. Thanks in advance.

Liteon

[andy_cytomic]

what is the exact code for rand(2) ?

Andrew Simper

[andy_cytomic]

Originally Posted by andy_cytomic

what is the exact code for rand(2) ?

Andrew Simper

The rand (2) function will probably be the source of your trouble, but I will need the actual code behind it to be sure.

Andrew Simper

[liteon]

Originally Posted by andy_cytomic

The rand (2) function will probably be the source of your trouble, but I will need the actual code behind it to be sure.

Andrew Simper

hello Andy,

rand() is the system function for Math.random()
rand(1) returns random number between 0 - 1

example:
0.51311565
0.15432537
0.91317364

rand(2)-1 will return values between -1 - 1


Edit:
I don't really know the algorithm used by Justin for the pseudo-random function in the engine (I'm not sure if he used the 'rand31' for example).

Since rand() cannot be altered, maybe some limitations can be applied for the rand() results at a given sample rate?

Please I don't really want to bother you in any way.
If you have better things to do just ignore this thread and my late question. :-)

lubomir

[andy_cytomic]

Originally Posted by liteon

Edit:
I don't really know the algorithm used by Justin for the pseudo-random function in the engine
lubomir

I can't help then, since I need to know that before commenting further. If you don't know then it might be a good idea to find out.

Andrew Simper

[liteon]

Yes, I'm interested to find out whats behind the rand() function.

Did the "long way" solution for different sample rates (in 4 ranges):

//
//init section
//
//trc - test rate coeff
trc = 1;
sr = srate*trc;
//******* case1
sr <= 48000 ? (
case = 1;
k0 = exp(-2*$pi*4752.456/sr);
k1 = exp(-2*$pi*4030.961/sr);
k2 = exp(-2*$pi*2784.711/sr);
k3 = exp(-2*$pi*1538.461/sr);
k4 = exp(-2*$pi*357.681/sr);
k5 = exp(-2*$pi*100/sr);
k6 = exp(-2*$pi*35/sr);
);
//******* case2
sr > 48000 && sr <= 96000 ? (
case = 2;
k0 = exp(-2*$pi*8227.219/sr);
k1 = exp(-2*$pi*8227.219/sr);
k2 = exp(-2*$pi*6388.570/sr);
k3 = exp(-2*$pi*3302.754/sr);
k4 = exp(-2*$pi*479.412/sr);
k5 = exp(-2*$pi*151.070/sr);
k6 = exp(-2*$pi*54.264/sr);
);
//******* case3
sr > 96000 && sr < 192000? (
case = 3;
k0 = exp(-2*$pi*9211.912/sr);
k1 = exp(-2*$pi*8621.096/sr);
k2 = exp(-2*$pi*8555.228/sr);
k3 = exp(-2*$pi*8292.754/sr);
k4 = exp(-2*$pi*518.334/sr);
k5 = exp(-2*$pi*163.712/sr);
k6 = exp(-2*$pi*240.241/sr);
);
//******* case4
sr >= 192000? (
case = 4;
k0 = exp(-2*$pi*10000/sr);
k1 = exp(-2*$pi*10000/sr);
k2 = exp(-2*$pi*10000/sr);
k3 = exp(-2*$pi*10000/sr);
k4 = exp(-2*$pi*544.948/sr);
k5 = exp(-2*$pi*142.088/sr);
k6 = exp(-2*$pi*211.616/sr);
);

On improving quality of random numbers Robin Whittle says on his site:

I can imagine having a short list, such as 7 words, of fixed but reasonably random-looking bits, to XOR each PRNG result with. Each result would be XORed with the next word in the list on a rotating basis. That would seem to be a good way of breaking up any patterns in the values of the PRNG - in this case in the "value" dimension rather than in the "time" dimension, as with shuffling.

I've been using exactly the same method to remove eventual patterns in block cipher i.e XORing the key + predefined (random) bytes from byte arrays. Here is the JS solution. 2 'vectors' v and k with lengths of 17, 21. Small random numbers are used.

//
//init section
//
//vector v
vi = 0;
loop(17,
v[vi] = rand(1)*0.001;
vi+=1;
);
vi = 0;
//vector k
ki = 0;
loop(21,
k[ki] = rand(1)*0.00001;
ki+=1;
);
ki = 0;

At the sample loop, I XOR with the result of rand(2)-1 but still limit the results to 1, with min():

//
//sample section
//
whitel = min(rand(2)-1+v[vi]+k[ki],1);

Here are some comparisons on different sample rates:



I guess the filters could be improved even further...
CPU usage hasn't change much since the original version.

Lubomir

[Mercado_Negro]

Liteon this time you took it too far with the 3BandPeakFilter! It sounds amazing, Hats Off!

2 Humble Requests (if it's not too much to ask ):

*Could it be improved with a couple of filters for highs and lows (HPF/LPF)? Maybe you could include on it one of those filters you've already made with a very musical cut.

* Could saturation be improved somehow (less noise adding)? Maybe a selectable input stage with a couple of algos could add some nice "color" to it too.

Thanks a lot for your amazing efforts!

[liteon]

Originally Posted by Mercado_Negro

Liteon this time you took it too far with the 3BandPeakFilter! It sounds amazing, Hats Off!

2 Humble Requests (if it's not too much to ask ):

*Could it be improved with a couple of filters for highs and lows (HPF/LPF)? Maybe you could include on it one of those filters you've already made with a very musical cut.

* Could saturation be improved somehow (less noise adding)? Maybe a selectable input stage with a couple of algos could add some nice "color" to it too.

Thanks a lot for your amazing efforts!

Thanks MN,
Will be adding some fixes here and there + some new stuff.

[Mercado_Negro]

Originally Posted by liteon

Thanks MN,
Will be adding some fixes here and there + some new stuff.

Thanks a lot sir! looking forward to it patiencely

[liteon]

modification to the 'apple filter' - 72db/oct hp/lp cascade.


hp:


lp:

^ consistency of Fc could be improved...eventually

cpu usage can go bit high for 12poles:

// *NOTE: You can use 'loop' for the cascade (see example below)
// however its many times less efficient !
//
// comparison for - mono, lp, 72db:
// --------------------
// using loop - 13.8% cpu 
// long version - 3.3% cpu
/*
i = 0;
inl = (spl0+spl1)/2;
loop(n_lp,
outl = a0_lp*inl+a1_lp*mem[4*i+1]+a2_lp*mem[4*i+2]-b1_lp*mem[4*i+3]-b2_lp*mem[4*i+4];
mem[4*i+2] = mem[4*i+1];
mem[4*i+1] = inl;
mem[4*i+4] = mem[4*i+3];
mem[4*i+3] = outl;
inl = outl;
i += 1;
);
spl0=spl1=outl;
*/

^
'loop' is faster than 'while'
gmem[i] is faster than myvar[i]

Other fixes:

13.02.09
- replaced applefilter with v.2 - up to 12pole hp, lp
- 3bandpeakfilter: reduced noise floor from the 'saturation' control
- 3bandpeakfilter: added 12db hp, lp - same as apple filter
- vu meter: default response time - 50ms
- pinknoisegen: should work with all samplerates now

[Mercado_Negro]

- 3bandpeakfilter: reduced noise floor from the 'saturation' control
- 3bandpeakfilter: added 12db hp, lp - same as apple filter


Thanks a lot Mr. Liteon! You're patience and dedication have no frontiers... really appreciated

[LOSER]

Originally Posted by andy_cytomic

what is the exact code for rand(2) ?

Andrew Simper

Rand() is implemented as a Mersenne Twister PRNG AFAIK, which should supply sufficient white noise.

[LOSER]

Liteon you might want to use the VST analyzer (in combination with the ReaJS VST (from landoleet) for analysis) http://www.savioursofsoul.de/Christian/?page_id=106
It will give you better information that SPAN IMO.

[drew]

liteon - just wanted to add my voice to the many here showing appreciation for your work. Respect!!

[dave dove]

+1

just starting to find your filters indispensible....

looking forward

dave

[andy_cytomic]

Originally Posted by LOSER

Rand() is implemented as a Mersenne Twister PRNG AFAIK, which should supply sufficient white noise.

So you are 100% of this for the reaper code? Also the fact that it's white noise is not the only thing to worry about in this case. I'm sure the author of the plugin will sort it out sooner or later.

Andrew Simper

[liteon]

Originally Posted by andy_cytomic

So you are 100% of this for the reaper code? Also the fact that it's white noise is not the only thing to worry about in this case. I'm sure the author of the plugin will sort it out sooner or later.

Andrew Simper

well andy,

i've added different filters for different sample rates. not sure if can do more...
(actually i can go out and buy a 192khz sound card to do more testing)

but rendering to different sample rates from reaper, produces relatively equal gain trough all octaves with this generator now. unless i'm missing something?

[Justin]

This stuff is great, liteon...

Oh and also yeah, the RNG is Mersienne Twister...

[liteon]

thanks justin,

i guess that solves the mystery :-)