Make into noise
Hello,
I've been trying to transform a relatively noisy sound source into pure pink noise (or white noise, for that matter). With this I mean a way to modify the energy distribution of the source sound to gradually approach a pure noise spectrum.
I've tried spectral morphing, but as is typical to FFT it sounds too full of artifacts/artificial (I'm looking for a more 'natural' sounding approach); I've also toyed with various configurations of delay feedback + distortion + filters but this has only a limited effect on the spectrum and a quite different character (more 'crunchy' than the 'hiss' of noise, if you know what I mean)
In the end I'm just looking for a way to 'noisify' an already noisy sound source. Any ideas, techniques or suggestions are welcome.
Thanks!
how about just crossfade with [noise~]?
I think I'll end up implementing a crossfade, but as a way of transitioning between states. A plain crossfade from A to B doesn't quite cut it for me (or perhaps I'm not that good at it — JF Charles suggests in another post that a capable sound technician COULD make crossfading sound as 'morphing').
Any other suggestions? (please, heh)
You could try a spectral cross fade.
A naive spectral cross fade won't be much different from a cross fade in the time domain, but you could give different weights to different spectral bands in the cross-fade process.
Hello Peter,
I'm just getting my feet wet in FFT land. After your reply I've been researching and experimenting with Max; the thing is I'm a little confused with all these different terms (mutation, interpolation, cross-fading) for what I think is the same goal: sound morphing. Perhaps I'm mistaken, and if that were the case, could you elaborate more on the making of a "spectral cross-fade with different weights to different spectral bands"? I'm trying to do this by myself but I'm afraid this is still over my head.
I think I've already done what you describe as naive cross-fading in the spectral domain: just using a regular cross-fader inside the pfft~, and indeed it doesn't sound too different to a regular crossfade (though it does sound like convolution, it also makes these inexplicable clicks). I've also read and played a lot with JF Charles' great tutorial patches, but I found that jit.matrix processing inside [pfft~] inevitably reduces quality (at whatever size and rate) of the output signal.
BTW, I'm working with 2 (continuous) signal streams as inputs, but I could reduce the noise input to a buffer~ clip. Below is my ultra-lame version of a so-called 'naive spectral crossfade' [pfft~ 1024 2]:
Thanks!
Ok, I think I finally made the necessary conceptual leap: under the assumption that assigning 'different weights to different spectral bands' is equivalent to making a dynamic selective EQ for the crossfade process in the frequency domain, I did a little more patching (please, correct me if I'm wrong). Now I'm storing a lookup table for the amplitude values of the 1024 bands stored in a [buffer~] and controlled by a [multislider]. I use this to interpolate between 2 different functions written in real-time on that buffer and looked-up via the FFT bin index, but I'm still not getting close to that mid-way morphing sound. Any suggestions?
store the fft info in a jitter matrix/buffer, reading from it in real time. then have jitter matrixes that are filled with noise and interpolate (jit.slide) between the two of them.
the terminology is probably way off, but hopefully someone else can explain it better
edit: nevermind, you said you didn't like the jitter in pfft thing. i find it works great! who knows
have one recording buffer of the original sound source FFT info, and one recording buffer of the noise FFT info. then have a third buffer, and interpolate between them using vectral~ to poke~ the third buffer, which is the one the FFT should be reading from the entire time.
i'll patch this up for you if i have time but you should try it out
Thanks man, I'll try it out but if you have the time then by all means please do your thang (it will probably be a lot better). I will also try the [jit.matrix] method, which is more straightforward than [vectral].
scratch the vectral idea. jitter is probably the way to go.
or another route would be to take the spectral envelope of the sample and then apply it to the noise, which fades in. then slowly remove the envelope (and fading out the sample), leaving the full spectrum of noise
hey radiotonga you really should check this:
https://cycling74.com/tools/live-spectral-processing-patches-for-expo-74-nyc-2011/
here jean-francois charles will give you a head start on how to do it using jitter matrices
This is only one way of doing what I had in mind. On a different day of the week I might have built the pfft~ patch as an external in C. Most days of the week I probably would have whipped up something using one of the mutator objects from Litter Power (lp.frim~ & Co.)
Anyway, with apologies to those whose work I have blatantly hacked at without making the least effort to cover my tracks, here goes:
Save this as "fftFP-mix.maxpat"
The save this into the same folder:
Exercise for the reader (not easy, but not impossibly difficult either) -- modify the pfft~ patch to work in 1/3-octave bands.
Thanks everybody for the input.
Nonlocality: Your idea sounds good, and it still might relate to your past idea in terms of envelope following. I'll see what results I can obtain
Floating Point: Yes I do have those patches, and for the life of me I can't get rid of that arctic watery sound on the output signal. I know FFT is about compromises, and I'm fairly new at this, but when passing a signal without modification through [pfft] it comes out sounding the same, whereas if I put a matrix I always end up with artifacts (even with Charles' patches). I think that's one layer of processing you can't negate when working with matrices, or maybe I'm just lame with the FFT.
Peter: A little procrastination doesn't harm anybody ;). Hopefully some day we'll see that C object, because concerning "third octaves" and logs, I still have to polish my school-level math skills (which to be honest, I can't remember I actually had — any readers out there?). Thank you for the patch.
and for the life of me I can’t get rid of that arctic watery sound on the output signal
yep I know what you mean-- it may be that more sophisticated transformation of phase is needed, not just manipulating magnitude, isolated from phase... maybe also a careful choice of window shape and overlap can help
when passing a signal without modification through [pfft] it comes out sounding the same, whereas if I put a matrix I always end up with artifacts
that is an unavoidable part of fft manipulation-- fft and inverse fft only work 'perfectly' when there is no alteration of the intermediate spectral representation. any change of the spectral content will produce --more or less-- 'undesirable' or unintended side effects. the art of spectral transformation and resynthesis is to minimise the artifacts that will by definition always be there
Glad to see I'm not alone here. I do understand that any FFT manipulation will produce those watery artifacts. I just meant that by that very nature of the FFT resynthesis, no matter how much you tweak shape, overlap, and size, jit.matrices will always add another layer of artifacts that is hard to ignore if you want the cleanest (most invisible) sounding FFT transformation. In the end it's a matter of trade-offs and how much of the FFT are you willing to accept into your final sound.
By the way, I found this post of yours that might at least point the way to purely mathematical aspect of Peter's exercise for the reader. Please tell me if I'm wrong here: https://cycling74.com/forums/multislider-log-scaling-fft-equalization/
maybe using max in 64-bit mode might improve things with fft -- I haven't really seen a need to go to 64-bit max, but maybe that might be a valid reason?
jit.matrices will always add another layer of artifacts
i don't think there is any reason that data transformation using jitter matrices would add to fft artifacts, any more than any other data-representation method-- on second thoughts maybe the kind of noise used to generate random phases in jit.noise is problematic...?
By the way,
aahh yep, when reading peter's post i thought i'd tried to do that before somewhere :)