discrete wavelet transform in reaktor

I've been doing exactly this for quite a while, now. With the 'first', with 'simple', with 'h' - I've rearranged everything in Reconstruction to match what I think the algorithm should be. I have yet to discover the magic arrangement (what you'd think it would be, it isn't, I can assure you), but I'm starting to get a better idea of what the differences mean. Whereas most implementations out there rely on convolution (whether circular or linear), this one uses the transpose of the transfrom matrix. Underneath, I believe these are the same thing, but implementation-wise there are differences (like the number of points used). I'm still working out what those differences mean.

I wouldn't waste your time on it. Your logic from the previous post is completely valid and there are, as you say, so many improvements to work on. You can actually implement those improvements (not something I can do). I can spend time on the philosophical side of things. Besides, I wouldn't class this as an improvement at all (unless a different implementation provides new/improved functionality - yet to be seen).

 

that's not quite correct. in the setup i've made, if you fed it those values, you'd get [.... 0 0 0 2 8 16 16 6 0 0 0 0 ... ] this idea of 2N-1 (isn't it actually N+M-1?) isn't something we really care about (2*infinity-1 = infinity, so technically the output does equal the 2N-1, in a weird sort of way).

 

( Yeah it is N+M-1) Ok - I was wondering about that.

Oh, but I found out why this implementation looks so different - it's because it IS different. It's using the properties of these wavelets that they're Quadrature Mirror Filters (QMF) or Conjugate Quadrature Filters (CQF). It means you can apply the filter with simple matrix multiplication and the multiply by the transpose matrix to get the inverse. In this case, instead of full-on matrix multiplication, it's just vector multiplication - an inner product - which is exactly what is happening on both ends (Analysis and Reconstruction).

The strange order of things in Reconstruction is due to the fact that those values (their positions) come from the transpose matrix. So if the original filter matrix is:
...
...h0,h1,h2,h3,0,0,0,0...
...g0,g1,g2,g3,0,0,0,0...
...0,0,h0,h1,h2,h3,0,0...
...0,0,g0,g1,g2,g3,0,0...
...
then the transpose would be
...
...h2,g2,h0,g0,0,0,0,0...
...h3,g3,h1,g1,0,0,0,0...
...0,0,h2,g2,h0,g0,0,0...
...0,0,h3,g3,h1,g1,0,0...
...

Multiplying the first one by the column vector
x[0]
x[1]
x[2]
...

gives the low-pass and high-pass coefficients for alternate rows.

Multiplying those vectors (the low-pass and hi-pass values, alternately) by the transpose matrix gives exactly the recipe that we have in the Reconstruction modules.

The last part of the wikipedia page on QMFs gives a little insight: https://en.wikipedia.org/wiki/Quadrature_mirror_filter

And yes, it is still convolution, but the QMFs are designed so that most of the multiplications don't have to be done because they're zero.

I think this places limits on what wavelets can be used - i.e., they have to be QMFs, but all the ones we've been using so far have fit that requirement (obviously).

 

ohhh matrices....
i remember vaguely in high school (11th grade maybe) - "i can't believe how easy this is"
then, it got more complex, i never bothered to learn all the rules, half-assed my way through the test, and then i never really used them again. i should re-learn that at some point.

anyway, i believe that i've read that one of the requirements for perfect reconstruction is a QMF, so i don't think that should be a problem.

 

hmm, scratch that, looks like there are other types of PR filter pairs:

http://fourier.eng.hmc.edu/e161/lectures/filterbank/node3.html

 

BTW, 64-channel only uses 3.5% on my system (that's with the FFT running, too).

 

The outputs from the wavelet packet transform may not be in frequency order. If you are working on the display and you get something like this:

from a chirp then let me know.

edit: for reference, if they are out of order, then here is the ordering for 16 channels:
ans =

1
2
4
3
7
8
6
5
13
14
16
15
11
12
10
9

 

yeah i think we're actually at O(log n) at this point (not O(n), like i said earlier) - you can double the number of channels with only a linear increase in CPU. this is great news!

i'm a bit jealous of those CPU readings though... i think my machine uses 3.5% just for the FFT!

thanks for the warning, i keep dragging my feet on the display. to build a simple one will be easy. to build anything that can be meaningfully expanded into something i plan on actually using at some point will be quite difficult.

so i'll probably just build a simple one for "full" decompositions like these where each signal has the same number of layers, to start.

 

I've got an older core i5 3570K running at stock 3.4Ghz (it's overclockable but my RAM is janxty) with 8Gb or RAM running windows 7, fyi. Some things it just tanks on, though... especially when there are iterators with large "N" values. And if I leave one of those "Event-Watcher small" laying around too long it starts to peg the CPU. Dunno why, I just delete it.

That's the biggest reason I want to visualize the wavelets right now... I'm just curious if the structure we're using builds in frequency ordering or not. If not, it should just be a matter of rearranging connections, right?

Defining product specifications is the first step! What do you actually want to use it for? Personally, I like to see the differences that different wavelets bring to the table. They all do PR, but that doesn't give any insight on what's happening in between. Also, eventually I'd like to be able to make a sample editor (maybe using the table framework? I hardly know anything about it) with an interface where you can click on the wavelet display to increase or decrease (mostly decrease) individual time/frequency blocks (as well as wipe out whole sub-bands). I think that could be useful to clean up drum samples, e.g. But all that is going to require a totally different type of interface than what you're talking about doing now, of course. And that wasn't a feature request or anything, btw - it was mostly just a ramble.

Eventually, for the multi-resolution case, you'll want to be able to specify the "width" of each sub-band in the display - but that's what you're talking about, right?

 

yeah, and the width will be calculable from the # of layers in that signal, so it's not like i need to do too much there... i'm just having a hard time visualizing the whole system at once. i need to just build something and then fix the stuff that doesn't work the way i want over several iterations.

 

i guess i'd just want it so that people could design custom setups and the display would automatically orient itself based on the number of wavelets and the topology of the transform.

the hard part is actually figuring out the total number of rows to use, because that's no longer something you can just calculate from the layers values, because the number of layers depends on which signal you're talking about. so i want to auto-detect the number of rows needed but that may have to wait.

 

Well, there's always one row per connected Modify macro, right? So maybe you could hook them up serially so that each one adds +1 to a variable and then pass that value out of the Modify Block and up into a Distribution module. It's kind of a cheap way to do it, but at least you don't have to determine what you're connected to or anything like that.

 

yeah i just implemented that, and along the way, each row also knows where it is in the sequence, so that if we need to rearrange them that should be possible too.

 

Cool! And here I thought I was soooo clever...

 

ours seems to start 1 2 4 3 8 7 5 6
haven't done the rest yet, but getting pretty close to something that can at least be tested.

 

Yeah, again I got the ordering from MATLAB, so it's entirely possible that there are flips in there. Luckily it's pretty easy to figure out what goes where with a linear chirp.

Oh, BTW, remember how you noticed that the fourth "first" filter I provided was all wonky? Well, I was smoking crack because nowhere was it described as I had it, and everywhere it was shown to be what I had provided earlier (the one that worked... "First"). That was just a SNAFU on my part - no great mystery.

 

alright, well, this display is not really what i was going for.
and right now the re-ordering is hardwired for 16 levels, it's the table in the display macro if you're trying to expand it.
but it seems to sort of work, for now.

 

Looks good - so what parameters are tuneable? Nvm I see. Looks like a good start, for sure.

 

Oh sweet you built the spectral freeze into it... nice! Oh nevermind lol... just the ramp oscillator...

 

yeah i had to freeze the frequency of the sine in order to actually see the order very very slowly.