IRDust (prototype convolver)

[mystran]

So basically, I wanted to write a basic convolution engine (low latency, long IR), for use in a couple of other projects. So I wrote one earlier this week. But then I figured, it might make sense to put it into a plugin with a simple impulse loader, since it appears that the selection of free convolution reverbs could probably fit one more.

So after about 2.3333.. days of hacking this thing together: IRDust (win vst 32/64 bit)
[edit: currently at version 0.1.0]


[Not final GUI design, just something for testing.]

At this point is largely a test: does it seems worthwhile for further development?

Three operation modes:
- mono-in: essentially "dual mono" with pre-width = 0% but saves some CPU.
- dual mono: process left input with IR1-left, right input with IR1-right
- true stereo: process left input with IR1, right input with IR2

NOTE: The output can be very loud unless normalization is enabled. I might add a limited later, but for now: You have been warned.

The "pre width" and "post width" controls will scale the side-channel before/after the convolution. These and the filters will only have effect on the "wet" signal, dry is pure pass-through with level adjust and latency compensation.

Latency is 128 samples (64 processing + 64 for resampling.. the processing part might go away at some point), processing is done in double precision.

There is an internal "safety" limit of 2 million taps (about 50sec at 44.1kHz), mainly because the double-precision processing uses quite a bit of memory. Anything longer than that will get truncated automatically.

IR must be be a WAV file with mono/stereo (no direct 4-channel yet, sorry). Any typical uncompressed formats should now work. It it refuses to load your files, let me know. Note that while it reports samplerate it doesn't resample anything.(this was fixed at some point)

It might crash and burn, as I obviously have not been able to do very extensive testing, since practically all the code is less than a week old.

The first 512 samples are processed in audio-thread directly, rest is done in background thread (one per instance), so host ASIO meters might not be too useful in estimating when it's going to start causing drop-outs (if the background thread is not ready in time, it will have to wait and the ASIO meter will spike suddenly). I'd like some feedback on how easily that happens, since it's partially a "performance vs. reliablity" trade-off and I could fine-tune is further.

[sinkmusic]

Thank you, Mystran, for one more nice plugin.
I can't download it : nothing happens
Can it be used for cab/amp sims ?
Do you think it could swap IR according to input volume (for instance, playing a short decay IR when the input signal is low, and a stronger reverb IR when the signal is loud) ? I think i have never sseen such a feature on any convo verb...

[mystran]

Thank you, Mystran, for one more nice plugin.
I can't download it : nothing happens

Urgh, really? Just check that the link works perfectly fine for me. I have some referrer checking on the server though (allow direct downloads from KVR and my site, basically, maybe there's a problem with that). Try copying the link address to the address bar manually, let me know if that works.

Can it be used for cab/amp sims ?

I should probably add bypass for the filters, but other than that, sure... why not.

It doesn't really care what the "IR" is as long as it manages to load it and you don't go beyond the length limit.

Do you think it could swap IR according to input volume (for instance, playing a short decay IR when the input signal is low, and a stronger reverb IR when the signal is loud) ? I think i have never sseen such a feature on any convo verb...

The feature is usually called "dynamic convolution" and it would kinda involve running multiple instances in parallel so you can cross-fade them. It's quite a bit more involved than normal convolution though, so I probably won't be adding such a mode into a free plugin, I'm afraid (the time to develop would be too much).

[mystran]

Oh and.. performance-wise, it's probably going to get faster in the future. Right now I'm using a rather simple FFT for everything, which could be improved.. and I could use some library for sub-blocks that don't need time-division.

Anyway, if anyone else has trouble downloading, let me know and I'll try to figure out if there's something cheesy going on..

[eidenk]

As soon as an IR is loaded there are constant spikes shown in the host (Cantabile 1.2) performance meter and they hit the max (with drop outs) all the time with soundcard (ESI Juli@ using its own ASIO driver) latency set to any other value than 512 samples. At 512 samples it constantly spikes too but only to about 40% only and so I get no drop outs.

CPU-wise it seems to be using only about 15/20% of my Opteron 154 2.8Ghz single core chip.

[No_Use]

Not much (if any, at least that I know of) free ones that do true stereo, so this is much appreciated.

Thank you.

Will give it a test drive and report back.

[mystran]

As soon as an IR is loaded there are constant spikes shown in the host (Cantabile 1.2) performance meter and they hit the max (with drop outs) all the time with soundcard (ESI Juli@ using its own ASIO driver) latency set to any other value than 512 samples. At 512 samples it constantly spikes too but only to about 40% only and so I get no drop outs.

CPU-wise it seems to be using only about 15/20% of my Opteron 154 2.8Ghz single core chip.

Thanks for feedback. The audio thread works only with very small blocks, so the issue must be that the background thread doesn't complete something in time. Given that it's a single-core system, that's certainly going to happen all the time, but the spikes would happen when larger blocks are late, which probably means that the internal sub-task division is too coarse. Working in larger blocks is generally better of CPU (less overhead, better cache use), but worse for real-time (larger worst-case latency).

But.. I uploaded 0.0.2 that uses somewhat more aggressive task-division, hopefully without increasing CPU use too much. Maybe you can try and report if it works a bit more reasonably?

edit: also.. if I manage to optimize the CPU use in the future (likely), that will help too.

[satYatunes]

Thank you so much for this plugin. None of the free ones has True Stereo mode. I just tried this in Reaper on Win 8.1 64-bit, loaded up Bricasti impulse (48K) and it's working like charm. Didn't notice any CPU issue but I played only briefly. I will report if I see anything unusual.

[eidenk]

With this version I get no spikes at all with a 2s long IR but max out with a 4s one.

It seems audio card latency setting has in fact no incidence on "load" spikes. I just hadn't been using the same IR after changing latency settings. I can't change latency of this card on the fly, all audio apps must be closed and latency can be changed only from the card control panel.

So with this version, no spikes at all with a 2s IR vs about 40% spike about every second with previous version but a 4s IR is still not useable.

[mystran]

With this version I get no spikes at all with a 2s long IR but max out with a 4s one.

So.. with 4sec IR, do you mean it spikes to 100% or does just plain not work at all?

So with this version, no spikes at all with a 2s IR vs about 40% spike about every second with previous version but a 4s IR is still not useable.

What sample-rate are you working on? The threshold for the largest FFT size is at 128k samples (about 2.9 sec for 44.1kHz) so there's a step in CPU use there (another FFT to process). For very long IRs it's still a net-saving, but I guess it might make sense to delay that until the IR is somewhat longer, which should result in a more linear CPU use growth. I need to experiment a bit though.

[eidenk]

With this version I get no spikes at all with a 2s long IR but max out with a 4s one.

So.. with 4sec IR, do you mean it spikes to 100% or does just plain not work at all?

It does work but I get a max out spike every second approximately on the host performance meter with accompanying audio drop outs/clicks.

And I have now noticed I still get 40% spikes with the 2s IR every now and then.

So with this version, no spikes at all with a 2s IR vs about 40% spike about every second with previous version but a 4s IR is still not useable.

What sample-rate are you working on? The threshold for the largest FFT size is at 128k samples (about 2.9 sec for 44.1kHz) so there's a step in CPU use there (another FFT to process). For very long IRs it's still a net-saving, but I guess it might make sense to delay that until the IR is somewhat longer, which should result in a more linear CPU use growth. I need to experiment a bit though.

48khz and I can't see the host + plugin cpu use going above 25% with external tools, process explorer, taskinfo and so on.

[mystran]

With this version I get no spikes at all with a 2s long IR but max out with a 4s one.

So.. with 4sec IR, do you mean it spikes to 100% or does just plain not work at all?

It does work but I get a max out spike every second approximately on the host performance meter with accompanying audio drop outs/clicks.

And I have now noticed I still get 40% spikes with the 2s IR every now and then.

Thanks, this is helpful, I need to investigate.

edit: Oh.. and .. sticking to power-of-two ASIO buffers (larger than 64) might be a good idea, I guess.. not that ESI drivers allow anything else anyway (at least mine don't)

[mystran]

One more note: when saving presets (or projects, whatever) the plugin doesn't save the IR data, just the original filename (including path), which will then be automatically loaded when the presets is restored. This is mostly to keep project files and such smaller, but .. well yeah .. thought I'd mention.

[sinkmusic]

As soon as i try to load an IR, i get an "unsupported format" popup window.

[mystran]

As soon as i try to load an IR, i get an "unsupported format" popup window.

Either it's not in a supported format, or it has more than two channels (should probably popup a different error for that). Right now only those listed above work (8/16-bit integer or 32-bit float). I'll try to add 24-bit tomorrow, just need to find some example files first. If it's something else, I'd appreciate details.

edit: also.. sadly there are quite a few variations on how to store the WAV data (or at least how to store the header data) and it's quite likely that I need to add support for more variations.. but I'll try to work on that tomorrow