Import RePhase output into buffir~?
Hi there,
I'm trying to build a FIR filter with buffir~
I have wav/csv/text... and some other output choices from RePhase
Is it an option with buffir~?
if you are unsure about certain specs of their output data just try it with a simple model (such as a butterworth lowpass at 1000 Hz) and see what happens.
with max 8, buffirs maximum has raised to 4096 samples and you should be able to use somewhat more complex filters without ending up with plastic sound, too now.
So I just did a 4096 taps file, 24 bit 192 khz wav (mono)
I struggled for hours to figure out how to import the wav file... got it working!
[read ~/impulse.wav] -> [buffer~ impulse]
[buffir~ impulse]
I just click on read anytime I change the .wav, I'll add a button to load everything, because other filters reset every time.
I'm not sure if the number of taps/samples is identical, but that works, I tried different numbers and ended up with crackling sound
So far so good, I could go full FIR and remove [filterdesign] , maybe there is a way to Plot buffir~ to check out its response like filterdetail&plot ?
just had an issue, it stopped working for a while, fixed it with [buffir~ impulse 0 4096]
no idea what happened nor why it works like that now
uhhh no, I'm reaching 100% CPU (one core) with a little over 4096 taps at 192khz using two buffir~, everything is crackling really bad.
that function doesn't scale much, it's maxing out one core out of 12.
I guess I don't need that many taps but I would have expected it to have more juice than a 400mhz DSP.
It looks like 4096 taps is the overall limit at 192khz, unless buffir~ goes multi core.
non-optimized convolution is extremly expensive, which is why this object has a length limit which raises from version to version.
you might try out some free IR reverb plug-in, eventually one with a "low quality" or "high latency" option, or, if you are crazy, you can also distribute multiple of your buffir´s into poly~ voices (loop up "parallel" for poly~)
furthermore, to assing stuff to different cores, you can also use multiple top level patches. i.e. put the FIR process in an extra patcher file, which has to be opened in background as top level patcher (not called by the other patch), and it will run on the "next" core.
another approach would be to run the same patch in 44 khz and use transferfunctions not longer than 512 samples for live, then enable your own "high quality mode" when rendering audio offline.
what I'm trying to accomplish is a full FIR active crossover, so I need 6 to 8 Buffir~ running.
Maybe there is a way to recreate the Buffir~ module externally in a multi-core c++ app?
Like a module with signal in and signal out, that runs on its own, there must be something out there already.
Basic filtering doesn't require more than 500 taps per filter, but a last pass across the full response would require 10k taps.
One core should be capable of running 50k~ taps easily, Idk what the overhead is, it's like comparing Python on its first execution vs Asm.
50k sounds more realistic that 8k, i agree. did you put the vectorsize to 2 or something like that?
(and maybe it is inadequate to ask, but why FIR?)
what vectorsize? in the adc/dac? (both at 2048, crackling below 1024)
Good question, I think it's easier to use than multiple chained filterdesign if the filter gets more complex.
RePhase gives me a nice output of what it's gonna look like.
Does it sound better? I don't know, not yet until my system is fully assembled, I'll compare both FIR and Filterdesign.
Due to the limitation, maybe I'll use a bunch of Filterdesign and keep few taps per channel to correct something if needed, unless I find a way to have more taps
i´ve had a look at that rephase program, and to be honest i dont understand why it shows off some stuff called "FFT" no matter what filter type you choose?
using a static filter seems quite right for a crossover, but until we find out why buffir~ steals your CPU cycles, biquad~ might be a more friendly alternative.
Looks like FFT is for RePhase itself to do calculations
0.9.3 2013-01-29
- FFT size can now be set by user (minimum size is two times the
smallest power of two equal or bigger than the requested number
of taps). Setting a larger FFT size makes generation and optimization
slower, but can increase the precision of the optimization and also
makes result curves more precise (just a visual effect for that one
though: no effect on the actual impulse)I tried the poly~ stuff, it gives me one more core, I had 20 polys running, still one more core, obviously both at 100%
Now running 1.024.000 taps, yes 1 million! success!
I'll post the module on GitHub after my vacation.
Based on OpenCL (for cross compatibility) + C74 Min, nothing too crazy.
CPU: 50% (reading from adc~/dac~)
GPU: 4% (RTX 3080)
The CPU side is not optimized, I can get that under 10% for a million taps.
I mean, nothing is really optimized but for a proof of concept that's pretty good.
50% CPU used to be buffir~ at 2048 taps.