R5 library ladder filter (look at this crazy thing)

Quote:"aside from all that though, it points to something about the method of oversampling filters employed today that i have always found confusing: the chaining of OBC elements between stages

i get that that z-1 elements need to share state for oversampling to work properly, but how does that work when, say for four stages, there are four chained "write" elements all being clocked at sample rate. which "state" is being passed though the obc chain? do they fight over it? take turns??? hopefully someone knows, to me it simply makes no sense"

they don't fight, it's just an unrolled loop!

for 3x oversampling, for each sample rate tick, the process needs to be repeated three times.

The crucial part is the state memory of the process which is usually some OBC like a z^-1, or some delay line, because that's the part that all the unrolled iterations need to share.

As long as the order is explicit (connected in series), and the last iteration is fed back to the first via a z^-1 so that the next tick starts its unrolled loop where the last finished, everything is just fine. no battles.

…the order of processing of the filter is left to right, and the order of processing of the unrolled loop is top to bottom…

So the top row is iteration 1, it passes it's output to the second row/unrolled iteration, applying res, and input2… all good.

I suppose the confusing part might be that the internal state of the individual poles is just connect vertically, so e.g. pole 2 of the top row connects its state directly to pole 2 of the second row. But if you think it though, it makes sense. That state value is only relevant to the second pole of the whole oversampled filter, so it can just pass down a column without breaking the logic of the process. It's passing it to the next 'iteration'. And for the unrolled part, it doesn't need to store it in OBC, it can just pass it on directly. It only needs to be stored after the last unrolled iteration so it can be preserved for the next audio cycle…

I'd like to know how oversampling is even possible. I always thought the sample rate needed to be four times higher and everything was underclocked except the stuff that is four times overclocked. You guys keep mentioning iteration. Seems like it spits out clocks or events higher that the sample rate. But yeah, I'd like to learn how it's done.

So the result gets clocked out. I guess if the result is closer than what it was then there's some kind of progress. So your basically saying it's just a way to approximate the value if it were truly oversampled.

So, there is a way to truly oversample by storing a series on values in a parallel fashion. For instance, a value is clocked in and after the next value is clocked, there is a gizmo that stores 3 values if it's a 2 times oversample. The first clock in value in one storage cell, The second clocked in value in another storage storage cell and an intermediate (calculated average) in the 3rd storage cell. So now we have an interpolated value in the middle which is an educated guess of a true sample taken if the sample rate were truly doubled. Now for a times 3 oversampling, there will be two additional storage cells that contain 2 interpolated values instead of 1 as the 2 times does. So the 4 times oversampling will have 4 interpolated points stored in a parallel fashion and so one. Ok, this produces a linear ramp between samples, I suspect the there's another gizmo that shapes these values base on the slew rate of the signal and fashions the interpolated points in more of a sinusoidal pattern instead of a linear distance between all interpolated points. Ok, I can visualize this working because the modules following this will deal with all of the interpolated points on the next clock. In a sense it's processing the interpolated points in a parallel fashion on each clock cycle. So in the end it gets compiled into a series of over sampled data. So the filters and what not using the interpolated data are actually processing 2 3 or 4 parallel data streams depending on the oversample multiple used. I think I starting to get the idea. In the end when the data gets clocked back out at the fixed sample rate, it's possible the values handed over to the serial clock will be slightly more accurate. It actually gets down sampled but can end up with results like filters working with an multiplied clock frequency. I think that's about the extent of it. Well, we do know that filters are borderline decent if they don't exceed one quarter of the clock frequency. So by oversampling, it equates to filtering at higher sample rates. That I can see, and if the interpolation scheme can come really close to a true higher sample rate and do a good job of simulating what input waveforms actually do then I probably would work better.

I have to admit it didn't seem possible at first because within Reaktor nothing happens at the same time. It first thought it makes you think parallel processing. However what I didn't realize is they can do many things in between the sample rate and the result is presented to the next sample clock. When the cpu usage climbs you know it's doing a lot in between sample rates. Then there is a time delay between the input and output and that makes it possible to interpolate between the successive actual captured samples after being read by Reaktor on the clock. So in essence it seems like internal oversampling most definitely has a input output latency buildup depending on the oversampling type; 2x 3x 4x etc. My initial guess is a times 4X oversampling system has an inherent latency of 4 samples. I bet it does, but if not then I'll really be blown away. lol I'll check it out and see if I can understand it. This will be a good test for dementia. lol

Yeah, the OS does toss data around it packets. But Reaktor still clocks the data in at the sample rate and does all of it's processing between samples. I think it starts out like that and the interpolators start filling in the dots after the sample value it clocked. So if a 4x oversampling scheme is used there are three extra processes going on; One for each interpolated data value. So in effect there are four parallel processes going in instead of one. So I see your point about overall latency as you can interpolate even 16 points before the next audio clock. Not sure how the reconstuction works but Reaktor still only clocks out one value per sample clock. It think the asio buffer deals with the operating system and the op system feeds sends data to the sound card. That must be what asio buffer overruns are all about.