Signaldust

sinkmusic · Post by **sinkmusic** » Mon Feb 10, 2014 8:10 am

I tried with various different IRs (For instance, the popular Bricasti M7 IR), and not a single one would load.
Maybe it was 24bit, not sure, i'll check asap.

mystran · Post by **mystran** » Mon Feb 10, 2014 9:00 am

sinkmusic wrote:I tried with various different IRs (For instance, the popular Bricasti M7 IR), and not a single one would load.
Maybe it was 24bit, not sure, i'll check asap.

I'll upload a new version in a minute with support for 24/32 bit integers and some header format variations. Just need to do some sanity checking on the build before I upload it.

mystran · Post by **mystran** » Mon Feb 10, 2014 9:18 am

Ok, uploaded 0.0.3 that should load 24/32 bit integer, and allow for some header variations.

Hopefully most uncompressed files should work now.

Ivan_C · Post by **Ivan_C** » Mon Feb 10, 2014 9:34 am

Very good idea right here !

A dumb question : have you read the few technical articles available about optimization of partitioned convolution ? I have a list of threads there and article links (I didn't have the time to read all of them yet) which may be useful for you, to find the best strategy to preserve a low/zero latency with a low CPU consumption and the right use of threads. You may know them yet, but I'm posting them here if they can be useful for you.

http://www.kvraudio.com/forum/viewtopic ... &p=4933534
http://www.kvraudio.com/forum/viewtopic ... 9&start=15

http://pcfarina.eng.unipr.it/Public/AES ... nt5660.pdf
http://www.ericbattenberg.com/school/pa ... Fx2011.pdf
http://www.angelofarina.it/Public/Paper ... nk2001.PDF
http://www.angelofarina.it/Public/Paper ... nk2003.pdf

mystran · Post by **mystran** » Mon Feb 10, 2014 10:23 am

Wolfen666 wrote: A dumb question : have you read the few technical articles available about partitioned convolution ?

I don't think this could work without some form of partitioning at all.

I currently partition with up to 6 different block sizes. The main problem is that currently the partition allocation is static, so it starts using larger blocks too early (currently as soon as possible) and it's pretty dump in terms of zero-padding the impulse (it always pads the largest block-size).

I'd like to fix both in the future by doing more intelligent partitioning, so I can wait (with growing IR size) until the overhead of processing in shorter blocks is likely to be higher than the cost of adding another FFT (should be easy to add), and allocate "excess" to the shorter blocks when possible instead of padding the largest one (need to figure out how to deal with the varying internal latencies without additional data copying).

mystran · Post by **mystran** » Mon Feb 10, 2014 10:38 am

Oh, and I use only a single background thread (per instance) for two reasons. First reason is that I'm not convinced that I can get reliable priority scheduling on Windows to work (especially in a random host with random selection of other plugins). Second reasons is that I want to reduce the chance of starving other background processes by having a large number of threads that might reserve all cores at once, even if some of the work could be delayed.

There would be advantages for multiple threads mostly on slow multi-cores where the individual cores are not fast enough to deal with the work alone. Maybe someday I'll add some work-around option for those, but for now the design is geared towards working nice with other software when running on a fast multi-core where a single convolution is not a significant work-load alone. On single-cores none of this matters, since it's all going to run on the same core anyway.

Ivan_C · Post by **Ivan_C** » Mon Feb 10, 2014 3:55 pm

What I meant isn't "do you use partitioned convolution" of course, but "how much do you use the knowledge from technical articles about partitioned convolution into your algorithm" instead

Reading your comments, I thought that maybe you are trying to reinvent the wheel in some places, and that a few issues you have encountered may be discussed somewhere. This was the dumb question I was asking

For example, the work of BruteFIR seems well documented and the result seems faster than most of the partitioned convolution implementations available in general, according to a lot of discussion I have seen on KVR or on musicdsp some years ago

http://www.ludd.luth.se/~torger/brutefi ... ruteconv_3

I hope that helps

No_Use · Post by **No_Use** » Mon Feb 10, 2014 4:06 pm

mystran wrote:Ok, uploaded 0.0.3 that should load 24/32 bit integer, and allow for some header variations.

Uhm, sorry, maybe I'm blind but where ?
Link in the first post is named "IRDust 0.0.1", or is that 0.0.3 ?

mystran · Post by **mystran** » Mon Feb 10, 2014 4:08 pm

No_Use wrote:
mystran wrote:Ok, uploaded 0.0.3 that should load 24/32 bit integer, and allow for some header variations.
Uhm, sorry, maybe I'm blind but where ?
Link in the first post is named "IRDust 0.0.1", or is that 0.0.3 ?

Oh.. sorry, forgot to update the original post.. just redownload the same URL link.

No_Use · Post by **No_Use** » Mon Feb 10, 2014 4:22 pm

Thanks, doing now and testing.

mystran · Post by **mystran** » Mon Feb 10, 2014 4:29 pm

Wolfen666 wrote:What I meant isn't "do you use partitioned convolution" of course, but "how much do you use the knowledge from technical articles about partitioned convolution into your algorithm" instead

Well, I'm aware of the literature on the subject. The basic design is somewhat similar to http://www.ericbattenberg.com/school/pa ... Fx2011.pdf at least on the abstract level.

No_Use · Post by **No_Use** » Mon Feb 10, 2014 4:55 pm

Working fine in Reaper32, Win8.1 (x64) from what I can tell so far, tested with True Stereo IR's.
Thank you for this.

Questions:

1.

NOTE: The output can be very loud unless normalization is enabled.

That's what I observed, but I wonder what's happening there technically.
Why is the un-normalized louder than normalized (thinking that normalization usually puts a signal to 0db).

2. Am I correct thinking that for now we can "only" use IRs with the same sampling rate as the current project ?
I tried to use 44.1 IRs in a 96kHz project and I think it kinda sounds not as it should (the IRs become "short).
Internally resampling the IRs in the plugin would be needed for this or ?
Might this be added at some point ?

mystran · Post by **mystran** » Mon Feb 10, 2014 5:31 pm

No_Use wrote:Working fine in Reaper32, Win8.1 (x64) from what I can tell so far, tested with True Stereo IR's.
Thank you for this.

Questions:

1.
NOTE: The output can be very loud unless normalization is enabled.
That's what I observed, but I wonder what's happening there technically.
Why is the un-normalized louder than normalized (thinking that normalization usually puts a signal to 0db).

Without normalization, the plugin follows the mathematical definition of convolution, taking the samples as-is. The output level is then related to the magnitude response of the total IR, which for long IR can be a lot louder than the individual samples as there is a lot of "energy" over time. Normally you still want to store the IR files that way (with reasonable peak-sample amplitude), so they are easier to edit and have better dynamic range in integer formats.

Note that if you feed the convolver (without normalization) with a single unity-magnitude sample, you get a (remarkably inefficient) sample player... but if you feed it 1 second of audio at 44.1kHz, then that's like playing 44100 samples on top of each other... which is probably too loud.

With normalization, the plugin takes the full response (over time) and scales it such that you get something closer to unity for continuous input. This way you get something more useful for typical IRs like reverbs.

2. I'm I correct thinking that for now we can "only" use IRs with the same sampling rate as the current project ?
I tried to use 44.1 IRs in a 96kHz project and I think it kinda sounds not as it should (the IRs become "short).
Internally resampling the IRs in the plugin would be needed for this or ?
Might this be added at some point ?

Yeah, it reports the samplerate, but doesn't resample anything yet. It's pretty high on the TODO list though and shouldn't be that hard to add.

No_Use · Post by **No_Use** » Mon Feb 10, 2014 5:47 pm

Thanks for the responses.
The first one is a bit over my head (well, I asked for a technical answer

), but I think I get the basic concept.

Very nice about the upcoming resampling, all I wished to become my go-to IR loader.

Thanks again.

mystran · Post by **mystran** » Mon Feb 10, 2014 5:56 pm

No_Use wrote:Thanks for the responses.
The first one is a bit over my head (well, I asked for a technical answer ), but I think I get the basic concept.

Yeah, well for reverb use the normalization is almost always what you want.

Signaldust

KVR Audio

IRDust (prototype convolver)