@solipp Thank you for contributing this library, I'm learning tons. I have some questions about fft-split~.

• It looks like you are simply passing the bins that are below the threshold frequency to the left inverse transform, and the rest to the right (with the omitted bins on each side muted), is that correct?
• If so, then why does the transition band sound continuous? i.e. when I output lowpass to the left and highpass to the right, as I sweep up it moves continuously from left to right around the threshold frequency.
• I struggled to make a test to see what phase distortions occur near the threshold frequency, and there don't appear to be any. Could that be true? (I'm not confident I tested properly)

@jameslo said:

• It looks like you are simply passing the bins that are below the threshold frequency to the left inverse transform, and the rest to the right (with the omitted bins on each side muted), is that correct?

yes, that's correct.

• If so, then why does the transition band sound continuous? i.e. when I output lowpass to the left and highpass to the right, as I sweep up it moves continuously from left to right around the threshold frequency.

that is the result of spectral smearing i guess https://en.wikipedia.org/wiki/Spectral_leakage
the slopes of the lowpass/highpass are not perfectly steep

• I struggled to make a test to see what phase distortions occur near the threshold frequency, and there don't appear to be any. Could that be true? (I'm not confident I tested properly)

there shouldn't be any phase distortion. essentially it's a linear phase FIR filter.

@tungee thanks for the links!
I made this pp.ladder~ filter to get an idea about the concept of "zero delay filters". So I kind of mapped it out as a pd patch to get an overview (not that i fully understand it now...)
However, it makes much more sense to create externals (instead of vanilla abstractions) of this filters. Pure data is really not efficient in processing patches with one sample dsp blocks.

@solipp I was wondering if fft-split~ could be used as an upsampled anti-aliasing filter but I'm not getting the results I expected. Things seem to change radically depending on the oversampling factor. What am I misunderstanding?
fft-split~ as antialias filter.pd

EDIT: NEVERMIND
It appears that Pd doesn't perform the 4X overlapped FFT windowing as expected if the FFT's block size is smaller than 4X the block size of the enclosing patch. When I change fft-split~'s block size to 4096, things are fine. But let me know if I've given the wrong reason.

@jameslo nja, i think you gave the wrong reason
if you run pd at samplerate 44100 and you upsample by 16, the samplerate of the patch is 705 600. Devide this by fft-split~'s default blocksize 1024 and you get a bin resolution of 705600/1024 ~ 689 hz.
This is like running fft-split~ with a blocksize of 64 at normal samplerate (44100/64 ~ 689). You can try, [pp.fft-split 64 4] will give you the same strange result (I'm not even sure why fft patches start to act weird when you run them with block sizes >256, maybe it actually is related to overlap...)
With block size 4096 you get 705600/4096 ~ 172hz resolution, but you probably want 705600/16384 ~ 43hz witch relates to 44100/1024 ~ 43hz.

Maybe someone can help me here. I LOVE the parameq~ object, BUT it resets every time I close and reopen my patch.
I've tried saving the patch after setting the parameq~ object, and I've also tried saving the parameq~ object once I've adjusted the EQ settings, but every time I reopen it has completely reset again. What am I missing here???

@Dizzy-Dizzy Before saving and closing your patch, you have to send manually a [save $1( message to right inlet of all pp.objects of interest (where $1 is replaced by a "preset"number of your choice).
When you re-open the patch, you have to send a [recall $1( message to the same inlets.

Amazing, thanks got it working! Always learning something new...

I'd like to use pp.fft-partconv~ on a long impulse response but I get the message "pp.fft-partconv-st~: IR length exceeds buffer". Do either of the creation arguments control the buffer length? Sorry for my laziness.

edit: OMG I am so lazy, what is my problem? It took 30 mins to find the answer, here's how:

• use text editor to search pp.fft-part*.* for the error message

• find subpatch that prints the message

• look at the condition that makes it print

• trace backwards on some of the receives that could make the condition true, e.g. $0-nparts

• notice that one factor in $0-nparts is $0-max-blocksize. Gee, that happens to resemble the name of one of the creation arguments.

• try it. Bingo!

@solipp said:

https://github.com/solipd/AudioLab

this is such a great collection, thank you for sharing with all of us

i'm fairly new to Pd, was wondering how difficult it might be to create a 7.1 preset in the spat8 patch? (ie Front L, C, R. Side L R. Rear L R, and sub?)

I tried just moving the speakers into position which worked but when I save and re-open it reverts to octophonic.

Any guidance will be greatly appreciated, thank you.

Sorry for not posting for some ... 2 years. Just a reminder that this project is still alive and slowly but surely evolving.
I pushed an update to deken today, v0.61. New stuff since version 0.4 include:

pp.fft-profile~ - esoteric spectral denoiser/vocoder
pp.loop.rec~ pp.loop.play~ - a pair of abstractions to record and play loops, but also useful for pitch shifting/reverse delays
pp.grainrev~ - a granular reverb, very cool
pp.phiverb~ - a good sounding reverb

many bugfixes and some new examples.

Make sure to use the latest version of pd (pd-0.55 at the time of posting).
In plugdata most objects should work but needs more testing.

@jewelzcotard sorry for the late reply, anyway if you moved the speakers in the gui, you can save with msg [save 1( to the rightmost inlet of pp.spat8~ and save the patch. A msg [recall 1( to the same inlet will load your settings.

Happy patching and make some noise!

@solipp said:

pp.phiverb~

what can you tell us about this new object? Where is the model from, what is it based on? I'm interested in reverb design

thanks

@porres
It is based on this talk by Geraint Luff:

However, the basic structure is the same as in rev3~, early reflections are fed into a 16-channel fdn. Delay times are selected from a table of prime numbers. The "secret" lies in the mixdown of the 16 fdn channels to stereo. It was more or less trial and error, adding and subtracting the signals and listening what sounds good.

nice, thanks

A new version is now available on deken, v0.63.

added 2 new objects:

pp.pantd~ stereo panner with time delay
pp.grainer-mc~ a granular sampler with multi-channel signal outlet

A new example 15-train_of_sounds.pd showcases the use of some audiolab abstractions with pd's multi-channel signal connections.
Example 14-glitchfest.pd is also new and just a lot of fun to play around with.

fixed some bugs as well.

Happy patching!

Simply Amazing thanks!

@solipp said:

https://github.com/solipd/AudioLab

Fantastic patches!

I can't figure out how to use the sidechain in the compressor. There's no key input, just an enelope out. Should I feed the compressor an audio signal somewhere or an envelope? I am confused. What is the sidechain preset for? Can anyone help? Thanks.

@qhr33k Thanks!

about this sidechain thing; yes you would need to feed the compressor an audio signal and use the sidechain output to let's say duck the tail of a reverb (that's just an example, you can do whatever you want with this). In this case you would multiply the 100% wet reverb with the signal from the sidechain outlet of the compressor like this:

sidechain_compression.pd

The presets are more or less didactic, you can use them as a starting point and then change the parameters until they fit your needs. In the case above you'd use the "compress" preset. I think what confuses you is the preset "Env.follow(sidechain)". This one is an envelope follower, the comment (sidechain) hints that the envelope is the signal from the sidechain outlet. Hope that makes sense?

Thanks a lot! i was looking for that patch point inside the compressor for days. I would have never come out with the solution of simply putting it outside the comp without you pointing to it. Thanks again your patches are gold.

Version 0.70 is now available on deken.

I added some simple but convenient objects:

pp.amp~ a simple signal multiplier
pp.adsr~ adsr/adr envelope generator
pp.xfade~ signal crossfader
pp.shiftlfo~ a LFO that can generate irregular rhythmic patterns

pp.dynamics~ now has an option to enable feedback compression

Some parameter sliders are now colored light orange in the GUI. This indicates that the slider does not cover the full range of the parameter and is intended to encourage experimenting with values that are above or below the range of the slider.

fixed some minor bugs.

Happy patching!

I just downloaded Audiolab to get pp.spectrum~ and I love it! Thank you for making this.