R5 library ladder filter (look at this crazy thing)

colB

https://community.native-instruments.com/discussion/comment/175522#Comment_175522

But Reaktor still clocks the data in at the sample rate and does all of it's processing between samples.

That doesn't make sense.

Reaktor knows how much buffer it needs to fill, and it uses all the available cpu to fill that buffer chunk as fast as it can go. In one part of the buffer, it might process 10 samples worth of 44100Hz audio in less than 1/44100 seconds… in another part, it might hit some slower code… maybe a blep or something, and take 2/44100 just to calculate a single sample of data…

That's why you get more buffer underruns with low latency settings… because there is less opportunity for 'lumpy' cpu requirements to average out.

ANDREW221231

https://community.native-instruments.com/discussion/comment/175408#Comment_175408

oversampling with ILO or blep seems to have really nice synergy in conjunction with simply being practical

one cleans up the most critical bandwidth and the other addresses partials to infinity

i think i tried asking you this before but did you ever try using ILO saturation for filter feedback? apparently addressing the ILO unit delay is as easy as adding a "dummy" filter stage and removing the FIR component

Studiowaves

https://community.native-instruments.com/discussion/comment/175566#Comment_175566

Sounds right, That's true, once the data has already been stored there is no law that says the data has to be read by the serial clock and processed in sync with the serial clock. I picture the ensemble doing all of the necessary calculations before the next serial clock and stops. After it stops then there is time to do other chores. I always thought the sample rate was a timed interrupt that ran all necessary calculations. However it doesn't really have to have top priority. Something else can interrupt the ensembles calculations and hand control back to Reaktor when it's finished. It seems the daw itself should have top priority of all interrupts because it has to run all of the tracks. I think the soundcards asio buffer is filled by the daw but the soundcard itself is running its own timed interrupt that sends and receives the data stream at the audio sample rate. This way the sound card is on its own and never really gets interrupted by the computer hardware. So yeah, there is no reason a precompiled ensemble has to follow any rules at all. Let's see. ASIO Asynchronous means not synchronous, or free to accept data at any time into the buffer. So it's a simple Asynchronous input output buffer. Only the input and output and synchronized to a serial clock in reality. Which basically clearly shows why short asio buffers have overflows or "Lost Buffers" as the saying goes. I get it now, the daw and all of the plugins don't have to be synchronized but they do need to be regulated so as not to overfill the asio buffer. I assume the daw does as much as it can without overflowing the asio buffer then stops processing. I guess the problem with clicks is when the daw can't keep up with the cyclic reading of the asio buffer. That's why a long asio buffer helps because that give more time for the daw to process everything. I think a daw does process all tracks and plugins as fast as it can but tries to run slow enough to it doesn't overfill the asio buffer. There might actually be a flag to stop all daw activity when the asio buffer is full. So the processor starts out fast and fills up the asio buffer and then rides on the tail end of the asio buffer, constantly feed it as much data as it can before it is halted again when the buffer is full. So in a sense, it is asynchronous at the start but ends up synchronized to the sample rate of the sound card after the asio buffer is full. The timeline position indicator on the daw is probably fake in relationship to what is actually happening. That about how I picture it because the iteration module can toss out a whole lot of stuff in between samples. At least that's what I think it can do. So if it can do that, it pretty much proves that reaktor doesn't really step thru all of the code one sample at a time. It sure seems like it though when you program in core.

colB

https://community.native-instruments.com/discussion/comment/175598#Comment_175598

I did try, with limited success, but was in the middle of another project, and I haven't had a proper look at it since then. Pretty sure it will be a back to first principals effort with a few days of 'do the math'… so not my favourite thing :)

colB

Overfilling the buffers is not an issue, it is trivial to just stop when its full and wait for the next empty buffer. There will be some sort of callback to the host to say the buffer is ready. The problem is not filling them in time, that's why the problem is called an 'underrun' - time is up, the DAW needs the buffer back, but it's not filled yet, so you end up with clicks and pops due to the missing data.

ANDREW221231

https://community.native-instruments.com/discussion/comment/175688#Comment_175688

yeah, this sounds about same as i just went through. was able to fudge around with the ZDF framework in and get something that seems to be working at least a bit, though trying to take it further ended up being a dud

what ended up seeming to work was taking the last 1p element a four pole ladder and changing the trapezoidal integrator into just a regular one, deleting (near as i can tell) the FIR element from the integrator as described in the paper to compensate for the half sample delay of the ILO (labeled 1p int in the structure)

the only thing i'm not really sure about is the calculation for cutoff , described in the paper as w2/(1+w2/2)

not sure whether also applies to the g and s parts of the zdf structure or not

really saturate1.zip