Operator precedence, value assignment, arrays, and things not working as expected....

[_Devin]

Hello all,

I have plenty of software development and DSP experience, but I feel like I'm missing something in JS. I'm trying to implement some filters(Biquad and State Variable), that I've had working on other platforms for years, I've even verified that the exact same coefficients are being generated at every filter tap vs my other working versions, but at the actual filter, it's exploding numerically. I've been creating assignment variables for the filter taps, for example:

Nm2=Nm1; //n-2
Nm1=spl0; //n-1

//filter code
spl0 = (b0*spl0)+(Nm1*b1)+ yada, yada....

//output taps
Np2=Np1;
Np1=spl0;

I'm really not sure what's going wrong, the cutoff frequency is not above or below the min/max stable value for the filter, my best guess is that the value assignments aren't happening how I expect them to, or maybe the lines of code pertaining to assignment are run sequentially like a script... Anyways, I would really appreciate if anybody has any suggestions.

Also, can anybody explain arrays in JS? Do I need to declare an array size, the JS guide doesn't really go into depth. Like C# stylee:

int[] array = new int[5];

I was trying to create a simple un-interpolated delay line, but it wasn't working.

[dub3000]

Originally Posted by _Devin

I'm really not sure what's going wrong, the cutoff frequency is not above or below the min/max stable value for the filter, my best guess is that the value assignments aren't happening how I expect them to, or maybe the lines of code pertaining to assignment are run sequentially like a script... Anyways, I would really appreciate if anybody has any suggestions.

Also, can anybody explain arrays in JS? Do I need to declare an array size, the JS guide doesn't really go into depth. Like C# stylee:

int[] array = new int[5];

I was trying to create a simple un-interpolated delay line, but it wasn't working.

operator precedence has always worked fine for me - i'd double check your coefficients. make sure you're compensating for sample rate and keep your resonance way down if you're anywhere at all near srate/2 unless you're implementing oversampling.

arrays in js seem to be (if i'm wrong, someone please correct me!) a bit weird - there's only one array, putting an array index on any variable looks into that array. so if you want multiple arrays, you need to do it like this:

array_start_0 = 0;
array_len_0 = 512;
array_start_1 = 512;
array_start_1 = 512; // etc
offset_0 = (offset_0 + 1) % array_len_0;
array_data[array_start_0 + offset_0] = blah;
array_data[array_start_1 + offset_1] = blah + 5;

there's a bunch of this stuff including a circular read/write buffer in the floaty js effect (and probably all the other delays as well).

js isn't great for readable code, refactoring, or any kind of sensible prettiness, but it is very good for prototyping up some cool stuff really fast. performance is pretty good, too (it's compiled directly into native code).

[zorn]

Hi,
speaking of dealing with arrays this thread http://forum.cockos.com/showthread.php?t=6027 might be worth mentioning.

[_Devin]

I got it working, AFAIK, it had to do with precedence, despite my gratuitous use of parentheses(not really sure why it works now but not then), but atleast it works. Now I have to troubleshoot a DC offset @ < 100hz issue, which can't be too hard. Thanks again.

[_Devin]

OK, confirmed a bug in the way floating point is processed, will report in the bug forum...

[_Devin]

Ummmm... Decided to play with it some more, the FP bug may not be as much of an issue as I thought(or it may not actually be a production bug, but a monitoring bug), and I have the filter working using the JS plugin array memory where a loop such as:

@sample
i=0;
loop(poles*.5,

spl0=filter calculations referencing buffer[i*blah+blah]

i=i+1; //wishlist: the ability to type increment as i++;

);


And it works just fine and stable, and the frequency response is substantially what I would expect at a given order, BUT... the CPU useage is ridiculous, I could set it to 100poles in theory, but in reality, my modern top-notch computer craps out at about 10poles(176.4k SR), displaying 20% cpu useage in the channel FX window for that plugin(on a channel with Reasynth in an otherwise empty project). I'm guessing there's some really poor memory management going on there in the arrays(calls to main memory instead of the CPU caching the <500 bytes of array data actually in use).

[dub3000]

Originally Posted by _Devin

i=i+1; //wishlist: the ability to type increment as i++;

you can use i+=1

Originally Posted by _Devin

And it works just fine and stable, and the frequency response is substantially what I would expect at a given order, BUT... the CPU useage is ridiculous, I could set it to 100poles in theory, but in reality, my modern top-notch computer craps out at about 10poles(176.4k SR), displaying 20% cpu useage in the channel FX window for that plugin(on a channel with Reasynth in an otherwise empty project). I'm guessing there's some really poor memory management going on there in the arrays(calls to main memory instead of the CPU caching the <500 bytes of array data actually in use).

tried pre-calcing everything? is there any division going on in there? some floating point ops are actually pretty expensive. you might also be bumping into a denormal problem.

the js engine turns everything into asm but i don't think it does any post-optimization, it's likely to be a line by line conversion. in any case i wouldn't be trying for 10x oversampling on a filter at 176.4k srate in a scripting language.

[_Devin]

Hi Dub3000,

Everything is recipricolated(tm), so there is no division going on in @sample, and very little in @slider. I've minimized unnecessary Flops in the @sampleblock as much as possible. It's not 10x oversampled, it's 10 poles, or a 5* 2pole cascade(the combobox control goes up to 16poles, but that ain't happening).

As far as denormals, what's the best way to go about fixing it in JS? I'd thought of this, but adding a smallish number to the unit delays didn't seem to help much(granted, I could experiment more). Any tips other than adding a tiny dc offset?

[_Devin]

I replaced the iterative pole adding version with an identical one without the loop(still using []), and CPU useage was the same for a single 2pole section(scaling linearly with CPU useage). I replaced buffer[0...7] with 8 declared variables, and CPU went from 6% to 1% for a single 2 pole stereo filter at 176400hz. Note to self: Don't use arrays in the @sample block. Ever. :P

[dub3000]

cool, good to hear.

just out of interest, how come you're working at 176kHz?

[_Devin]

My reasoning for 176.4khz: I produce EDM using 90%ish VSTs I coded myself from scratch(primarily Reaktor5), higher samplerates pretty much accomplish any oversampling that would be needed for filters to be stable and clean at high cutoff frequencies. Of course, hihats and other high-freq materials sound far cleaner in the mix at higher samplerates(even when not apparent solo'd). I used to produce at 88.2 when I had a Core2 Duo e6600 maxed out, but after I bought my Phenom 9500, I started doing 176.4k just because I could(and not running out of CPU). And finally, I have nothing against 48khz multiples(obviously, good resampling algorithms don't care if it's a multiple of target samplerate or not), but my soundcard freaks out at multiples of 48k(random white noise, instability), whereas it's rock solid at multiples of 44.1... Bizarre...

EDIT: Actually, case in point, the JS filters I'm working on now wouldn't be stable near the nyquist(without oversampling) if I produced at 44.1khz. However, I can wholeheartedly endorse producing at 44.1khz for everyone else who uses commercial plugins with built in oversampling, frequency warping, etc... Production technique plays a far greater role than samplerate.