discrete wavelet transform in reaktor

yeah, the iterator doesn't technically need to do all that work, it's pretty much a cludge. it redraws the whole thing every time even though honestly, only a small part has been filled since the last iteration.

you've certainly got a problem with the width there, there are some values of '8' somewhere that should maybe become 12? edit - oops looks like you mentioned that....

there are some 256's in the modify macros that would need to be changed as well. honestly all this stuff should be global constants that you can declare, i should work on that.

 

I got all the ones I could find... I mean, that was pretty much the algorithm: "Replace 8 with 12. Replace 256 with 4096. Bigger numbers, figure out their factors, if either is 8 or 256, then you know what to do...".

I encountered the same shifting effect in the one I modified before - I was thinking that maybe it could have something to do with the latency of those lower frequency analyze macros...? Just a long shot.

 

did you edit the offset macro?
you should change the 255 in there to 4095. leave the 63 alone.

 

Yeah, I found that one already. Also changed all the ones in the Modify macros to globals.

I seriously encountered the same thing when I tried to do things this way - I think I even posted about it. By "this way" I mean add the partition number to the fractional X value in order to get the X coordinate. Do that for both X1 and X2.

 

okay, try a longer chirp i don't think the problem is necessarily with your display?

here's my fix, it should autogenerate almost everything. you can't autogenerate the array size or the number of objects in the display, unfortunately.

 

the 'trouble' is that there appears to be a substantial amount of leakage (or maybe some FM components?) as we move from one bin into another. then, because the lower frequencies have a long appearance on the graph (due to there being less values to chart there), they appear to be further to the right than they actually are.

 

That previous one was a 2s one from 20Hz to 20kHz.

Here's the sine oscillator you included at 3Hz:

Here's the oscillator at 0.1Hz:

Just to be clear, is it your fix for the shifted lower frequencies? Or just for what's necessary to change the MD settings and make it still work? Because I get the same results in all 3 test cases I've described with 0.933, too.

 

i know it looks weird, but i think it's right. the lower frequencies have no real time localization (1 or 2 values every 4096 samples, when the chirp length is 18000 samples, you don't get much data)

 

Right, I mean, that makes sense, but I feel like it wouldn't be so regular in that case - there would be more variation. It should be shifted to the left sometimes, too, right?

Also, ok here's the thing that gets me - the backswept tail is clearly several partitions shifted to the right (forward in time), and each partition is calculated in isolation from the others, and at no time does the chirp ever produce more than one frequency at a time, so there is a partition that admits to detecting multiple frequencies simultaneously... So that should show up in the reconstruction. But the reconstructed signal is accurately reconstructed from this same data and it never has more than one frequency at a time.

The more I think about it and remember oddities of when I first discovered this, the more I think that it's an effect of putting all these small windows side-by-side and treating them like they're a single analysis... The problem I have is that, if that is what it is, I don't understand what the limits of the effects of that adjacency/small-window-size are (because that's not just a problem with visualization, since we're displaying all the data, and accurately). If this is an accurate representation, then how will this effect affect audio processing?

It's a puzzler, to me anyways.

 

Ok, so I plugged a Note Pitch into that sine oscillator, disconnected the FM, and hooked the Gate to an AR, then a multiplier with the output of the sine oscillator, then into the DT cell.

I played the lowest note on my keyboard and here is the picture I got... very interesting:

I tried it without the envelope and it's the same thing. I don't know yet how to explain that...

Oh, and there was no noticeable delay between me pressing the key and the very tip of that little tail...

 

maybe a little bit of aliasing? were the attack and release times set? envelopes can easily cause minor aliasing.

either way, i dunno, since the sound reconstruction is perfect i don't think anything happening behind the scenes is wrong - the magnitude being graphed is the same value that gets converted back into a complex number and reconstructed, after all.

 

oh, i don't think that's true, i think what you're seeing there is the distortion that occurs when the frequency moves from one band to another, across the whole spectrum. it's just way brighter at the lower frequencies than elsewhere.

and in the case of the 3hz wave, that's actually the beginning of the next chirp.

 

this version only updates the necessary part of the display, much faster. in addition i fixed an error where the display was too bright (which was accentuating the problem)

 

okay, i think i realize now what the problem with the display is, it's maddeningly simple, can't believe it didn't occur to me already.

the values at the very top are not delayed very much during reconstruction. the values at the bottom have the largest amount of delay. i'm guessing that we need to apply the delay to the display as well! i may or may not have time to fix it today, but pretty confident that's the issue.

 

i haven't nailed it completely yet, but i have applied the delay during the modify macros rather than the reconstruction. it looks much better, but still some strangeness.

it makes a lot more sense to do it this way. for one, it explains partially why the spectral freeze i made sounded so awful - i was freezing different frames of the signal! now we can apply effects in a much more sensible manner (i think).

i need to fix the reconstruction and test with FFT to make sure everything's working, then i will post.

 

okay, updated once again.

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

you'll note, the response still looks smeared. for example, the new chirp seems to begin before the old one ends. this time though, i think it's right

update - fixed yet one more time... not sure if there are any other improvements to make (except that little corner in the upper left hand side that doesn't get drawn )

 

I think it's right, too. It looks good. Even if the visualization suffers some slant-wise distortion (start of the next chirp overlaying the end of the previous), it's consistent and it makes a lot more sense than it did before.

I'm going to try it with the packet version, now that the delay has been moved to the Modify part.

I don't know that there's any solution for the heavy load caused by the Iterator, except to split the MD into multiple ones. The high N value isn't strictly necessary except for the visualization, right? I mean, that's why it has to go up so high - the Idx for the MD module, right?

 

well it would probably be faster to calculate exactly what needs to be drawn and then loop thru only those values.
right now it loops thru all values, and checks each value to see if it needs to be updated or not. it could be much faster but tbh the display for me is really only there for verification of what's what, it's not really going to be in any finished projects (other than, say, a spectral analyzer, of course).

i doubt this will work at first with a packet version.
i think each h[n] signal may need to carry information about it's own delay time.
anyway, if you get all the filters made and things don't line up horizontally, don't worry. send it my way and i'll try to get everything back into phase and see how we can auto-generate the delays and display in a packet setup.

 

also, if there are more layers, each 'frame' of data is much longer. right now i think it draws 64 frames, but it could draw less, that would free up some CPU

 

Well, that's easy enough. Changes are only in the Analysis Block.

edit: I forgot to hook up the "layers" macro to the Analysis output, so there's that. My modified Analyze macros made it in there, actually, too, so here are those changes: each h[n] and g[n] pass on the same info (wavelet, Hi, Lo, real, imag, and layers). That's about it.