'simple' INTERP LP filter..

Maddogg6

The dane guide shows:
Is that correct, and why am I not seeing how a 'simple one sample delay line' is created here. ??
Is this inherent to the INTERP instruction? - or is a 'static' declaration missing in this example?
Or does the CONTROL with INTERP do this?

Something seems wrong here - is it just me?

Lex Nahumury

The "out" register functions as the filter's memory here.
(btw printed in bold)

Maddogg6

Ok - its just me
Yeah I did notice that.... but,
Is it because its the nature an OUT register - or because its used as R and A - or used as R and A with INTERP instruction.

When can I expect this 'one sample delay' to occur - I guess might be the better way to ask this.. ??

edit: nvmnd : I found this..
So its the OUT register...

Thanks Lex...

Russ

In other words, OUT is a static register ('static' in this context, meaning that it retains its value each sample cycle).

From the examples section of the guide:

Maddogg6

ok I hope my next question will not be so dum... dum dum. dum.

Im reading up on filters and see that IIR and FIR filters are differentiated by 'feedback' (re: DSP GURUs FAQ)

Am I to understand this 'feedback' described is much like 'feedback' for a 'traditional' delay/reverb.
In other words - if I re-send output of one samples filter operation back into tram - and use that instead of a 'non-fed-back' but 'delayed' value - I would now have an IIR filter.
Other than coefficients - is that the only 'programming' consideration I need to be aware of?
In other words - Can I tell by the lack of such feedback operation in existing KX filter plugins - that they are FIR and not IIR? Or vice versa? (If there IS feedback - its definitly an IIR filter ??)

*hopes that made more sense , than me sounding dum*

Thanks,
Mark

Russ

I think that you will find that most of the more complicated filters used in existing kX plugins are IIR filters because they require less resources to implement.

Feedback here means a recursive filter (filters use previous outputs and (usually) inputs).

i.e.
If you look at the difference equation for the filter, you might see something like the following:
y[n] = b0*x[n] + b1*x[n-1] + b2*x[n-2] - a1*y[n-1] - a2*y[n-2]

In the above:
y[n] is the output of the filter
y[n-1] is the previous output of the filter
y[n-2] is the output from 2 cycles ago

x[n] is the current input (current sample)
x[n-1] is the previous input
x[n-2] is the input from 2 cycles ago

You wouldn't really use Tram to implement the delays here, rather you would just use static registers.

i.e. (code implementation would do the following)

y = b0*x + b1*x1 + b2*x2 - a1*y1 - a2*y2
y2 = y1
y1 = y
x2 = x1
x1 = x

The above is used for most of the EQ plugins bundled with kX.

Max M.

speaking of "interp out, out, k, in":
it feeds back the value of the out register delayed by one sample (hense "delay" and "feedback")

Russ

BTW: I should also add that your typical echo delay using Tram would also be an IIR filter, but I was trying to make the point that Tram is not necessary (i.e. if you a trying to use Tram as the identifier).

I guess that would be true in most cases (unless you are using the feedback for some purpose that results in it not effecting the impulse response in any way).

Maddogg6

Ok - I think I get it. (Max's Explanation of 'delay' and feedback' - seems like a reasonable interpretation to me - Thanks to both of ya)
Tho - it seems more like plain old 'delay' - than 'delay+feedback' to me...
DSP GURUS use of 'feedback' must be more derived from 'feedback' from resonant active analog filters.. (doh!- that makes more sense too)

Ok - I didn't realize they were using statics to achieve delays of > 1 sample. I thought I seen one use iTram - but I could be mistaken - Ive been looking at alot of DANE...so... ??



Ok I got ya... (*forgot most any DSP algo can be referred to as a 'filter as well - but my previous use of 'filter' was aimed at what you assumed correctly - LP/BP/HP)

Is there a FIR filter example (in DANE) in existence? - so I can get a better understanding of just how much resources are needed - looking at the formulas - it would look like ~ 3x amount of instructions (guessing) - but wonder what the audible difference there would be as well - seeing as I read IIR are 'less accurate' and 'prone to errors'.
My experiments have seemed to be 'noisy' and wonder if this noise was from 'errors' I read about. ??

Thanks guys.
Mark

Russ

That shouldn't be an 'and/or', rather it should be 'previous outputs, and (usually) previous inputs' (I corrected it above). FIR filters can use previous inputs too.

A plain delay would be:
out = previous_out

'interp out, out, k, in' would basically be:
out = (1 - k) * previous_out + (k * in)

Notice that among the other calculations, previous_out is added to in, thus feedback.

I do not know if there are any of the more complex kind (I haven't really looked at (and analyzed) the Dane code for every plugin).

Well I am not an expert, but as I understand it, the errors are not so much of a problem with a DSP with a double wide accumulator (like we have here).

As for your noisy experiments, I do not know...

Maddogg6

Ahh yes - yet again you are right and I was ....not
I wasnt looking at the interpol - as 'mixing' but I guess it is.

Prolly more *my* errors than the algos...


hehe - I warned ya...lolz

Thanks again Russ...

Maddogg6

Ok I have yet 1 more question...

Im looking at a HP_LP Filter made by Radiocolonel.it (havent seen him around in a while..??)



Anyway, he used a static register, but is assigning a value to it.
1) is this valid - and ONLY uses that value upon plugin translation? (as opposed to every sample) - or

2) is it simply ignored?

Russ

Yes, that is how you would set the initial value (think of filter coefficients, etc). It would only be ignored if you wrote to it before using it (which would defeat the purpose of declaring it static (not that you couldn't do that if you wanted to)). It uses that value when the plugin is first loaded and until such time it is overwritten (by a DSP instruction or from C++).

BTW: In most cases, Dane will not let you do something that is not 'allowed' (it would give an error when updating the code, and when trying to save, and when trying to load the plugin).

Max M.

btw. this code above is ill formed. all 'temp' registers there must be 'static'
(that code works only because kx's loader interpretes 'temp's as 'static's anyway
- as we recently discussed in 'using accums' thread)

As for FIR, well, you won't find any FIR based equalizers within kX plugins - simply because: to achive a frequency response comparable to what IIR is capable of, you need to build a FIR with thousands of taps (e.g. thousands registers and thousands MACs).
(although there're a few 'vacuous' fir filters in plugins here and there - for example a simplest lowpass with cutoff at FS/4 (e.g. 12kHz) is just a two tap fir (but the lower frequency - the more taps you need)

Lex Nahumury

@maddog6:
In addition to what Max mentioned,
even if you would implement a usable FIR, the delay it introduces
could render it useless for 'real time' applications.

Best to use the well known BiQuad IIR implementation.
(See Soeren's filter plugins)
As you can see there's little that hasn't been done yet in emu10kx.

Btw; What is it you are trying to develop if I may ask?

Maddogg6

Ok thats what makes most sense

Well I *am* finding out it does allow me to make bad algos.

Ok - just so Im crystal clear...

temp - if assigned an initial value (temp y = 1) - and like static - is only assigned this value upon plugin loading - BUT because we *usually* write to FIRST (before reading it) it every sample - its assigned to new values every sample anyway.
static - if assigned an initial value (static y = 1) it will only be set to that value when the plugin is first loaded.

So now, If Im understanding correctly -
The only real difference is if we READ to it or WRITE to it first?
Ie -
(referring to each sample cycle)
TEMP - Write it first (gets rid of last samples value ) - then read it
Static - Read it first (gets last samples value) - then Write it

But - I should not be looking at it this way - as it can change later.. ??

I know Im dense on this - sorry - the bolded part in Max's post above is kinda confusing me (or at least is contradicting what I thought I was beginning to understand ..??).

Ah - this is exactly what I was looking for - those are 'Bi-Quad IIR' - thank you.

is that a challenge - ?? lol - I can come up with *some* kind of new ideas. (see below)

Well - at them moment Im trying to get a grip on filters - I have enough reference to design and build electronic analog ones - and have on several occasions - but never had all the engineering part to deal with (ie, intensive math) - just Fc = XXXXXX for this circuit; Fc =XXXXXXX for another circuit.
Which transpose into determining the discrete components values for those circuits.

But you have (in an audio demo you made a while back) inspired me to try making some simple amplifier/cabinet simulation filters (to replicate the more significant aspects of their freq response - maybe (prolly) not all the detail)
Well thats the more immediate goal I am aiming for anyway.

Also - If nothing else - So I can re-create some of the DSP configs I made using a bunch of plugins into fewer plugins. (simply save resources, remove un used controls/features and/or combine controls that have previously been in separate plugins) (this may also explain my fixation on 'shared' global registers to Russ)

* multi-band distortions (possibly bands determined by or based on amp models - maybe adjustable bands??)

* multi-band compressions (to save resources used when I did this with multiple plugins - maybe eventually - I hope)

* simple amp sim - with (smooth) slider control between 'rhythm - solo' channels (variable mix of treble boost (Fc > 1-6 (adjustable too) Khz) + clip)

* 5.1 compressor w/ single controls for all 6 channels - or maybe separate threshold/ratio & gain controls for the (front& rear) + (center) + (lfe) if possible for DVD's and such. - ok not 'filters' but is another one of my hair brained ideas to save some resources when I did this using multiple plugins (well - I used 2 separate compressors for 4 channels.)

I wont even get into my ideas for midi implementations on some of these.

- But - Im hoping I can eventually make a C++ plugin that can receive MIDI tempo and adjust a delay time. (IE - Im pretty sure I can do this using a tempo controlled 'beat' sent to the plugin - with say Midi CC sent every Nth note.) AKA tempo delay - but Id have to paste the 'tempo' MIDI CC's in a track sent to KX Control of course - not a problem IMHO).
Id probably need to make this with multiple plugins ('Ping-Pong - 500ms' , 'Ping-Pong - 1000ms' 'Slap Back - 700ms' - etc.. to avoid dynamic 'tram' allocations - set 'time' limits to each plugin - I dont mind converting time to bpm & vice versa - but figure this can be calculated and displayed in the plugin - and thus I can see if my 'tempo' is out of that plugins range)

Then take that concept to MIDI/Tempo based VCO (volume, envelopes & panning) - to eliminate that 'zipper' problem - sorta like how portamento is usually implemented.

Then theres that 'Adrenalinn' thingy by Roger Linn - something... err (I forget his name now - theres 2 guys working on similar units) has this cool idea for beat synced vocoding (or thats how I'm thinking it works anyway). But - imaging a vocoder (or a wave shaper, or Nth delay taps) that is mixed with a tempo based or beat triggered envelope.
This may need to be a VST ?? for any decent results - I guess I'll figure that out along the way once I get a grip on some of this stuff.

OK - I lied and *started* going into them....

Oh I have ideas - that is NOT were I'm lacking.... lolz. A sense of reality - probably, the knowledge to do these things - definitely ... but oh - I got ideas.

Thanks again guys...

Russ

Under normal circumstances, you would think of 'temp's as having an undefined value (i.e. could be anything) at the start of your code (every cycle), so you would not use it before writing to it yourself (as the value would be meaningless to your plugin).

'static's on the other hand, can be used however you want, but, if shared 'temp's were to be implemented, you would want to use them as appropriate, as it would save GPR's (i.e. use 'static' if it should retain it's value between cycles, use 'temp' if 'static' is not needed).

Leave it to you to find the one plugin that would break if shared 'temp's was implemented.

Maddogg6

See - I told ya so....lolz
At least now, I know Im not a *complete idiot* for being confused with this... (edit: ok at least this isn't the evidence of it)

Max M.

>that code works only because kx's loader interpretes 'temp's as 'static's anyway

i can re-phrase it : "the code contains errors, and it works as expected only by pure accident"

Tiger M

Lex Nahumury

You misunderstood. I meant; every basic DSP algorithme has already been implemented..!

Your ideas, mine (and practicaly anyone else's for that matter) are build using those same basic 'old' algos.
So in that context there's little room to come up with something really new.
As such, it was meant as an advice to study the better examples within kx fx lib.

Anyway,.. Nice ideas!

Maddogg6

Th