IRDust (prototype convolver)

[mystran]

Uploaded 0.0.4 that should improve performance somewhat.. no other changes in this version.

[mystran]

Did anyone try the last version? I'd like comments on how it performs on slower systems...

[eidenk]

Sorry for not answering earlier. It's bad here, see gif anim for Cantabile load meter with nothing but 0.04 with a 2s IR and everything else completely idle.



I was thinking it might be OS related (as you may remember I am using Windows ME), so if nobody else's got that kind of issue, please just don't waste your sweat on it (I'm satisfactorily covered for free convo reverb with Reverberate LE/CM anyway).

[mystran]

Sorry for not answering earlier. It's bad here, see gif anim for Cantabile load meter with nothing but 0.04 with a 2s IR and everything else completely idle.



I was thinking it might be OS related (as you may remember I am using Windows ME), so if nobody else's got that kind of issue, please just don't waste your sweat on it (I'm satisfactorily covered for free convo reverb with Reverberate LE/CM anyway).

Oh thanks for that animation. I didn't remember that you were on Win ME, but the animation is very enlightening. There seems to be a scheduling problem, and it's probably my fault and could happen at least on XP too.

The bright side is that I have an idea how to fix that.

The thing is, on my dev-system (sandy i7), I get a load of about 1% of so, and it's a bit tricky to estimate how reliable the timing is in practice, because in order to measure anything I have to average a lot. So I'm sadly working somewhat on a theoretical basis, and practical feedback like this is very helpful.

[mystran]

uploaded 0.0.5.. eidenk I'd appreciate if you could try this one quickly and see if it still behaves the same?

main change is more intelligent dynamic priority scheme for the worker threads, it now attempts to run just above the GUI thread ("above normal") most of the time (with dynamic boosting to time-critical if audio thread is waiting), so hopefully things should work better now, as long as host audio thread is running at a priority higher than "above normal" ... which should hopefully be the case most of the time.

In the future I'll try to add logic to figure out the host audio thread priority and automatically decide the worker base priority based on that, but for now the fixed logic should hopefully help.

there are some other tweaks too, especially to the "mono-in" performance mode, but nothing major

edit: found a bug in the dynamic priority code, so priority boosting might not work correctly.. will fix in a minute

[mystran]

0.0.6: fix dynamic priority scheme so it actually works (at least in theory.. don't know what happens on old operating systems) properly

edit: for some reason 64-bit build seems to eat a LOT more cpu compared to 32-bit build.. I have no idea why this happens.. it makes no sense, but I'll try to figure it out in the future

[eidenk]

You nailed it with 0.06, bravo!

Tested with IRs up to 20s long and no problems at all, perfectly useable here now and it seems to be using no more than about 10% of my 2.8Ghz CPU which is all great.

[mystran]

You nailed it with 0.06, bravo!

Tested with IRs up to 20s long and no problems at all, perfectly useable here now and it seems to be using no more than about 10% of my 2.8Ghz CPU which is all great.

Ok, so the problem wasn't speed as such, but rather the fact that it was probably scheduling the worker before the audio thread. Great to hear that it works now.

[mystran]

Finally figured out how to get 64-bit to perform the same as 32-bit.. turns out the compiler apparently was doing something stupid with standard library complex numbers in 64-bit builds.. replacement with a custom complex number class seems to fix the issue.

I'll try to do some other fixes before I upload a new version, though.

[mystran]

Had an unexpected influenza attack, but finally managed to throw together a new build with some fixes.

0.0.7, main changes:

- now automatically resamples impulses at load time; unfortunately linear-phase resampling requires some latency, so this build now has 128 samples total latency; I'll probably try bringing it back to 64 in the future, but 128 (~3ms@44.1k) should still be quite tolerable [the resampling code is new; it appears to work but please report any oddities]

- couple of additional fixes in the convo engine, performance of 64-bit build should now be similar to 32-bit (unlike previous builds where it was quite a bit slower)

- added very simple RMS meter (combined input vs. output color-coded)

- there is now an experimental work-around for mouse-wheel that should enable it to work in hosts where it normally doesn't .. it's not enabled by default as it might still need some work, but click my logo at the plugin window bottom corner (for the "framework" menu) if you want to try it .. you might need to reopen the plugin window after changing the setting.

[Halma]

Hey,

I hope you feeling better now. Dangit totally forgot about your subforum.

Should have made a post here too about the 15 TILA2 patches though I think they are not that special. But I had them on my HD for quite some time now and never got the hang of finisheng them.Until that request. But maybe some of them are good starting point for further tweakening. Because until now they are more or less mathematical models without any optimization.

And I totally missed this one. Unfortunately I can´t test it right now but will do it a little bit over the weekend. Basically speaking this is a simple IR Reverb thingy? Don´t get me wrong about that "simple" term, I really like the idea. Just curious what I could load into them or use it for because I am 99% algo reverb until now so not that experienced with that IR stuff.

Edit: Nevermind. I have found your short description in your sticky.

IRDust is a simple prototype low-latency (64 samples) true-stereo convolution plugin.

Wow! Low-latency & True Stereo? Now I am really interested...

Regards
Sebastian

[mystran]

And I totally missed this one. Unfortunately I can´t test it right now but will do it a little bit over the weekend. Basically speaking this is a simple IR Reverb thingy? Don´t get me wrong about that "simple" term, I really like the idea. Just curious what I could load into them or use it for because I am 99% algo reverb until now so not that experienced with that IR stuff.

You can load pretty much anything you want (ignoring the stereo controls and filters, it just does plain old convolution), but reverbs where my primary goal (though.. now that I think of it, maybe there should be a pre-delay control too).

[mystran]

IRDust is a simple prototype low-latency (64 samples) true-stereo convolution plugin.

Wow! Low-latency & True Stereo? Now I am really interested...

Well, 128 samples currently to allow for the linear-phase resampling.

But.. yeah.. I'm not a big fan of low latency, and 2x2 matrix stereo allows some optimizations over running two copies of mono-to-stereo engines, so.. why not?

[Halma]

And I totally missed this one. Unfortunately I can´t test it right now but will do it a little bit over the weekend. Basically speaking this is a simple IR Reverb thingy? Don´t get me wrong about that "simple" term, I really like the idea. Just curious what I could load into them or use it for because I am 99% algo reverb until now so not that experienced with that IR stuff.

You can load pretty much anything you want (ignoring the stereo controls and filters, it just does plain old convolution), but reverbs where my primary goal (though.. now that I think of it, maybe there should be a pre-delay control too).

Now that you mention missing pre-delay: most of the time I use all of my reverbs (yours and others) with three diffeernt cue sends in front of them. One of them without and the other two with a delay, 100%wet and 0%feedback and some ms (eg 35ms & 50ms) as a "pre pre-delay stage" which then sum up with the internal reverb pre delay time eg another 15ms.

Never thought about if it would be possible to have an option in having 3 different stereo inputs in one reverb each with its own predelay time and if the idea make sense in general...maybe the cuebus setup is already the most functional one...I could see a benefit in having those 3 predelay times all at once in one device and at a glance but somehow I am not sure how easy that one would be to setup in a daw......and maybe I am a little bit to tired and need to go to sleep.

Regards
Sebastian

[mystran]

Never thought about if it would be possible to have an option in having 3 different stereo inputs in one reverb each with its own predelay time and if the idea make sense in general...

I have thought about it. I have thought about it a lot, because it would be something that would make a lot of sense in a algorithmic reverb that allows more realistic positioning of individual sources, but can combine the processing cost of several sources in the same space. But the DAW setup mess is exactly why I've not really considered it for reverbs that only do levels and pre-delay. IMHO it's easier to just setup a few sends that do the delays and feed to the actual reverb.