discrete wavelet transform in reaktor

So are you interested in feedback on this version? Or are you planning another rewrite?

 

if you have an idea to make it look better, throw it out there, i have some improvements to make...

 

closer to what i was going for.

quite a bit of distortion in there... looks pretty good though. once again it's eating a lot of hidden CPU. an obvious upgrade would only draw the necessary parts of the screen.

it should adapt to more rows, and draw each row with the appropriate width (depending on the # of layers in that row) to line it all up properly. but you'll still need to re-arrange the rows by hand in order to get a system that looks good.

 

This one is beautiful - exactly what I was going to suggest. It looks exactly like what the MATLAB ones look like. Uses 10% CPU on mine, but it spikes now and then so I see the little bar turn orange briefly. I'll do the 64-channel version here in a minute and see what effect that has - but it shouldn't have any (besides the small amount caused by processing the wavelets themselves) because every level you increase, you double the number of rows, but you halve the number of points, so the total remains the same. Oh, but the number of columns is defined in there, so the CPU would go up because the iterator's N goes up.

From experiments I've done in MATLAB, the way to reduce those perpendicular "crossbars" is to use wavelets with a larger number of points. I accidentally used one with 45 (!) and they were almost entirely gone at level=5.

That gives me an idea (sidetrack)... What about instead of defining the wavelets like we have been, instead you define them in a table (I think I mentioned that before, but in the context of making it easier to import them) and iterate through to do the multiplications so that the number of points isn't so hard-coded? I know that's a pretty major change, but it definitely adds a whole new dimension of flexibility.

 

iteration doesn't work in core. if it did, we'd be looking at a very different structure (i'd not have a modify module for every single freaking row, for instance...). you can pipe in iterations from primary but it's extremely inefficient.

just be warned that rearranging all the rows by hand is going to suck. they're all stored in a table in the display macro. we need an algorithmic way to do it. i haven't looked at the pattern yet but i imagine some method exists for automatically re-arranging everything.

 

ha! okay, well i don't want to go that deep, but we should look at trying to at least reduce those at some point. not a priority to me right now.

 

the maxlayers macro is incorrectly hooked up in that version.
attach it to the output of the analysis block instead, it should halve the CPU. the orange bar is caused by the huge iterations, i need to only draw the necessary part of the screen now.

 

I know I read about it in a paper somewhere, I just need to figure out which one it was. I remember the crux of it is to mostly "invert" the bottom half of the tree, but I'm not clear on what exactly "inverting" a binary tree means. It's more than just flipping the output rows. I think every node gets reversed?

Are the Analyze and Reconstruction blocks the same as earlier versions (0.937 is what I think I got them from)? Because then I can just copy/paste them in...

 

Ok, here's a version with 64 channels. Note the following:

1) I copied/pasted the Analyze and Reconstruct blocks from a 64ch version of 0.937 I made earlier (the Modify macros had obviously changed so I redid those)
2) In the Display block macro there was a hard-coded "15" that I changed to "63"
3) I changed the number of Columns from 8192 to 2048 (it was really laggy otherwise)
4) I increased the number of objects in the MD and the size of the arrays in the Modify block

Something isn't right because it's only active in a very narrow strip all the way to the left of the display, and the rest of the display is black

 

did you increase the number of values in the table and fill them in up to 64 rows?
might be easier just to use the 'drawRow' quickbus in place of the values being read from the table.
then you can suss out the new re-arranging pattern

 

okay i looked at it
the modify macros are different now.

 

new version in the UL.
basically a slightly optimized version of what i posted earlier.

https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/10025/

 

top priorities:

- figure out and implement variable-layer delay times (how to keep everything in phase when one signal goes thru more layers than other signals). [ edit - now implemented, however there are issues with the display to fix now ]

- implement automatic re-ordering of signals to their correct spectral location (especially within variable-layer systems). present implementation hopefully can be changed to a simple re-arranging of the bundles entering the modify macro (highly doubtful, but please let it be that easy). [edit - i've got this working, don't waste any time on it, check out this site if interested - http://www.bearcave.com/misl/misl_tech/wavelets/packfreq/ rather than do the re-wiring as suggested, i've simply written a simple macro to translate between the actual position and the desired position]

- automatic re-sizing of the 'columns' global constant depending on maximum layer length.

- eliminate or drastically reduce perpendicular crossbeams, hopefully without 45 coefficient filters! i assume the less we see those, the less we'll hear aliasing, but i have no data to back that up.

 

interesting paper here, mostly dealing with wavelets for medical devices, but it has some interesting info about the 'harmonic' and 'musical' wavelets (also called 'newland wavelets' after their discoverer).

http://moodle.fct.unl.pt/pluginfile.php/45280/mod_resource/content/0/wavelet_corrigido.pdf

in short, for daubechies wavelets "spectral leakage is substantial", while "newland wavelets have their spectrum tightly confined, thus drastically reducing spectral leakage."

assuming they have perfect reconstruction, this is the way forward for removing crossbars without an absurdly long filter length..

edit - unfortunately, they may have an entirely different implementation though! they seem like a pain to me, but at least we have identified the 'crossbars' problem and maybe there's some other wavelet we can use in place of the daubechies?

 

this is interesting too, the 'empirical wavelet transform':

ftp.math.ucla.edu/pub/camreport/cam13-33.pdf

i don't think it's actually what i'm looking for, but it looks cool.

i think the author has a MATLAB library or code depository or something on the web too.

 

okay, here's the first working example of a multi-rate system. the lowest frequencies travel through 5 layers of decomposition, the highest only have 3.

notes:

- delay is automatically compensated for different layer lengths.

- all structures have been increased to allow up to 32 frequency bands.

- graph automatically reconfigures depending on filter topology.

- as always, the topology of the reconstruction macro must be the exact inversion of the analyze macro. the example in the demo should make this clear.

- note that there are two types of analyze and reconstruction macros now. the pattern they use should be easy enough to figure out.

- everything has been re-arranged so that the lower frequencies are at the bottom (g0[n], g1[n], etc.). this is a far more intuitive setup imo.

- frequency tracking is kind of abysmal. yes, the chart looks fine and all, but we need a substantially finer resolution at lower frequencies. the graph should look linear when charting a pitch swept sine (as opposed to a frequency swept sine like in the ensemble). in addition, there is a crazy amount of distortion in this setup that you can see if you graph by decibels instead of amplitude. conclusion:we need wavelets that are better suited for the task at hand.

 

This is a sweet ride... Awesome work.

So finding three sets of wavelets that fit the requirements (QMF, first different from h, simple) but are all the same length might be difficult. Is there a way around the "same length" requirement? Or is that something that I just made up anyway? Also, how "deep" do you think we should go? I guess there's no way of knowing exactly until we try some others out. I'm willing to build out what you've made already into a 20-point version. Double what we currently have is a convenient amount for comparison.

The pattern that is defined in the "h" and "simple" wavelets should be appropriate for any QMF wavelets, respectively. The "First" wavelet only affects the high frequencies, so I think we can stick with that one (for now), but I haven't used anything but the Farras wavelets for the "first" ones, so I don't know how unique the pattern is. I suspect it translates to other wavelets, too, but I can't say for sure yet.

 

Okay, here's a side-by-side of db5 and sym5 ("symlets"), both 10-point QMF wavelets. Sym5 is on top, db5 is on bottom. The differences are very small, if there are any, but I believe the symlet provides slightly less distortion in the display.

Also, it's funny that the displays not quite in sync - I wonder why that is? I literally selected the Dual Tree and the MD and hit Ctrl-D to duplicate...

 

okay, here's an ensemble to give you a better view of the problem.
instead of graphing the amplitude, which isn't really how we hear sound, this one charts from -60dB to 0dB, with -60 and below being black.

lots of distortion, but the sym is slightly better (edit -actually maybe not? you can freeze it by turning off the reaktor CPU.

 

let's try to stick with same length, it's important for the delays. i guess each signal could carry a successive delay time if absolutely necessary.

can't any wavelet be stretched to cover any length? i started reading a book and that's the impression i got. in fact, each successive filter in a bank is technically stretched due to downsampling.

i'm trying to find a good source on the harmonic packet wavelet. i found a book on google books that seemed to spell out the algorithm pretty simply, but then two key pages weren't part of the review, of course.

currently we're splitting frequency linearly, we want to split it exponentially.