the new wavelet ensemble in the ul

has anyone messed with these? my understanding of fourier transforms is pretty solid, but it seems that offers no advantage here. the index does not climb linearly but interspersed as one would expect from a multiresolution transform

after at least 30 minutes to pin down the very odd jumpy index to only play the amplitude at that given index, all i could say is what gordon cole said after that man's head was eaten in the back of the FBI car: what the hell?

looping though every available index gives what they call in the scientific community 'total jumble'. there seem to be multiple broad bands in some bins and tiny super narrow single bands in others. depending on the wavelet sometimes these bands will have significant aliases, which i think is somehow the wavelet answer to complex analysis? i don't think there's any way in hell there's enough going on when looping though the index to account for the total output

the whole thing is very strange and mysterious and i sense some moments of great uncertainty before it can be sorted out

 

To shed some light on the index:
The wavelet transform is done using high- and lowpass filters to split the frequency spectrum.
Each of these half bands are again split into high and low part. This is meant by "multiresolution".

Viewed as a whole this looks like a tree.The nodes of the tree are numbered in ascending order.
Input is 1, split into half-bands leads to 2,3, further splitting leads to 4,5,6,7 and so on. (see attached pictures)
The easiest tree configuration (index wise) is the "packet"-transform, where all indices are located on the highest layer.
For example you get index 4 (0 to 1/4), 5(1/4 to 1/2), 6 (1/2 to 3/4), 7(3/4 to 1=sampling frequency / 2).

The dyadic tree configuration seems (index wise) confusing, because the indices come from different layers. (see attached pictures)

If you want to convert the index into "offset" and "width" e.g. to draw the spectrum, you can use the attached Core-Module.
"offset" gives you int numbers from 0 (=lowest frequency band) to 2^MaxLayers(=highest frequency band).
"with" is 1, if the index comes from the highest layer, 2 from the layer above, 4 from the next layer above,...
If e.g. "width" is 2, then the "offset"=4 means that band 3 and 4 are combined (higher time resolution, lower frequency resolution).

I know, that it is more complicate to deal with multiplexed data (by index).
The advantage of this is, that one "wire" contains all the spectral information.
This is much easier to scale and much more flexible (tree configuration changeable).

 

To shed some light on aliasing of the wavelet transformation:
If you play around with the "WaveletTransformOverviewDemo", you can see aliasing in the FFT-Analyzer clearly.
Dual-Tree and higher order wavelets (steeper filters) reduce it, but there is no perfect filter that filters out everything in the stop-band.
Combined with downsampling this leads to aliasing.

The stationary wavelet transform may be used (not (yet) included in JoWa), which does not use downsampling.
But this leads to extremely redundant data and even higher cpu costs.

So its up to the user of the library, to make decisions how much aliasing is acceptable.
Maybe i will add stationary wavelet transform and double-density due tree one day...

Finally it has to be said that soloing/muting single bands is a extreme modification of the spectrum.
Aliasing is much lower, if the amplification of bands is held within a smaller range.
I guess, multi band compression and vocoding may be done using the wavelet transformation.
If you look at the ensembles build on top of the FFT-Libraries in Reaktor, you will see,
that there are also some "tricks" (neighbor bands partly modified) to get around this.

I will leave this up the the user of the library

 

if aliasing is a product of downsampling, prefiltering in the signal chain before reaktor would help with that, correct?

 

I‘m afraid, no. If you e.g. filter out everything above 10k at sampling rate 44.1k, you will get no aliasing in the first layer, since the signal is prefiltered. But multiresolution goes on and the next layer will produce aliasing. This is, of course, only the case when the spectral data gets modified. Without modification, perfect reconstruction (except rounding errors) is guaranteed.

The only possibility to reduce aliasing is redundancy/oversampling like dual tree or double density or both. Aliasing free is - as far as I know - only possible without downsampling using the stationary Wavelet Transform (atrous algorithm).

If you find something else, please let me know.

 

i spent a substantial amount of energy on wavelets, but the big problem for me at the end was that the latency became huge if you wanted to have more than a few banks.

i could never think of a workaround, it seemed like something that was baked in to the algorithm itself. is that correct, or did you find a way around that?

 

I know what you mean.

Breaking down the classical filter structure by factorizing it into lifting steps reduces cpu and latency a bit.
For the 9/7 (bios 4.4) wavelet i get 150 samples latency for four layers including decomposition and reconstruction.
The FIR filter structure needs 180 samples. That doesn't sound to bad, but....

It depends largely - as you say - on the number of blocks/layers and the filter length.
latency = filterLength * ((2 ^ layer) - 1) * 2(to include inverse transform)
For 10 layers with a filterLength of 6 (for the 9/7 wavelet) this would be 12276, which is 278ms at 44.1kHz.
With lifting - i get a equivalent of 5 as filterLength - this would be 10.230, which means 232ms .

This is not practical at all.

When i started, i thought that you can get a very low latency for the part that doesn't need a high frequency resolution.
I was wrong, because you need to align (latency delay) everything to preserve perfect reconstruction.

To wrap it up:
No, i haven't found anything else than limiting the layers to 4 or 5.
And yes, i also think that this is because of the algorithm of the tree structure and the dependency of the filters to the output of their predecessor.
I try to read more papers about the multiplier-less stuff and VLSI implementations. Maybe those guys have found a way....

 

I see what you were saying about the tree structure and why i was confused.

anyway, maybe this could be of interest, this a modification of a tutorial ensemble uploaded a long time ago. its based on heterodynes, which is related to the constant q transform, which i know are related to wavelets somehow. it uses sine oscillators for resynthesis and it can be modified to output amplitude and phase, but the conversion is expensive. there is basically no latency, only the schlup schlup kind of sound which i believe is due to group delay or group phase or something, from the filters

 

just realized that in the above example the phasey sound only becomes apparent after changing pitch and that fixing it requires reinitializing the ensemble... interesting

 

Thanks! Sounds interesting. I'm gonna read more about heterodynes.

As far as i heard about "constant q", it focuses on - logarithmically seen - equal "broad" frequency bands and does not deal in detail how these
filters are realized. "Constant q" may be realized with "normal" filters in parallel or with a dyadic wavelet tree.
To get more control about the bandwidth of individuell bands (as with flexible node tree configuration in wavelet transformation),
"tunable Q" (see Selesnick...) is a interesting topic.

The ensemble sounds cool with finger snapping and a feedback between speaker and mic (my notebook). Very funny!
Could be build into the feedback path of a delay....

I read some papers recently and there is one thing, that called my attention in respect to the problem "latency":
IIR filters in wavelet transformation
They have lower latency.
IIR and "all parallel" are also the reasons why your ensemble has such a low latency.
But i don't know, how stable they are and how "nearly linear phase" sounds like. I have to try that out.
In simple theory there is no linear phase IIR filter. Linear phase is a demanded feature when doing multi band stuff.
IIR seem to be very unpopular in conjunction with wavelet transformation, but that may only be my perception.

I also looked into "m-band" wavelets. If you reduce it to only one layer and do all the filtering in parallel, you might get lower latency.
But as soon as you use them in a tree structure, you get (as far as i thought about it) the same latency issues.
I also read about efficient realizations via integer and multiplier less implementations, but that is only a solution to get a lower cpu consumption.

That said, you have to deal with latency and get it under control, but i try not to get too crazy about that one topic.

 

i actually considered a 'zero phase' method which uses IIR, but that involves segmentation into blocks, applying filtering, reversing, and filtering again, reversing again. so it wouldn't really help with latency and it was pretty glitchy trying to do it with the delays in reaktor. i think i did get it working in the end though

actually, thinking about it, there might be an advantage because the block size is not dependent on the filter length. at that point

but yeah, for stuff like this i don't care too much about a little latency either

as far as heterodynes, here's a link to the original ensemble which includes a short pdf explanation
https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/4133/
also a link to the site of the guy who invented the transform
http://www.mmk.ei.tum.de/fileadmin/w00bqn/www/Personen/Terhardt/ter/top/ftt.html

 

Thanks. The ensemble and the description was very helpful.
And i definitely need to try out multiple voices in Reaktor.
Also your other stuff is really amazing. I bet that was a lot of work.

I looked up "zero phase IIR" and found a nice description:
https://dsp.stackexchange.com/questions/9467/what-is-the-advantage-of-matlabs-filtfilt

This meets what i have read so far on IIR filters:
It is not possible (afaik) to get a causal linear phase filter. Using "tricks", it is possible to design linear phase IIR filters,
but these are non-causal and that means a delay (latency) needs to be used to get them causal.
There are also nearly linear phase designs.
(causal means that your function/system is not dependent on future data and only needs the current and maybe older data/samples)

Now, i have learned a lot more and need to dive deeper into these topics.
There seems nothing to be easy in DSP.

 

the original isnt my work. i just modified it to be able to make use of the phase instead of just amplitude. credit goes there to one gabriel mulzer, unfortunately he doesn't seem to post here anymore, though i have found a lot of his old threads very educational.

the whole zero phase thing, while i don't think it was a new idea, IIRC there was some guy on the flowstone forums who made some great breakthrough in realizing it. i remember the thread..... everyone basically called bullshit that he could do the thing he said he could do, but then he produced results. it actually ended up in some acedemic papers, and one guy was like you gotta email Siegfried Linkwitz with this. lol

it seems the delay required would be very small compared to those needed for low frequency FIR filters, just a small block for a buffer. i think with these things tricks is what it all comes down to

i remember the guy even boasting that any artifact from windowing is automatically resolved because the backwards filter undoes the damage. if i can find the damn thread again ill post it