Problem with low pass filter smoothing is that it doesn't reach to the desired value.
The lower the slew rate, the lower the "resolution" of the output.

@tungee Haas effect is already implemented in your brain, it's a psychoacoustic effect

I guess you want is a small delay between two output channels. You can do it with [pp.sdel~] samplewise delay.
something like this:

assuming you have the abstractions in your path, here is the patch:
interaural.pd

edit:
if you change the delay times over time you can get some nasty phasing effects depending on the position of your speakers. it works okay with headphones though.

@Laevatein do you want to avoid externals in general?

my spoonful of wisdom if you want to do something like earplug~ with pd-vanilla objects only:

First you'll have to figure out how to do the panning between your channels. basically you have two options, vbap (vector based amplitude panning, read: https://ccrma.stanford.edu/workshops/gaffta2010/spatialsound/topics/amplitude_panning/materials/vbap.pdf) or dbap (distance based amplitude panning, read http://www.pnek.org/wp-content/uploads/2010/04/icmc2009-dbap.pdf).
Actually it's just triangulation, not too complicated stuff. You'll find many open source code examples online, including pd-patches, e.g. [pan8~] in the else library or my humble implementation [pp.spat8~] in audiolab are dbap. Both are available in the deken repos (help -> find externals)

The convolution part is a bit more complicated. You can do it in pd-vanilla, there are some examples in Alexandre Torres Porres live electronics tutorial, which is now part of the else library i think. But if you care about latency or if your IR files are larger than a few hundred milliseconds you'll have to use partitioning. Again, you can find examples online. Tom Erbe shared something a few years ago, there are patches in else, in audiolab ... Problem is though if you're doing the convolution part in pure data and you'll need to convolve with say 8-16 stereo impulse responses to get a decent binaural effect... it will bring your modern day computer to it's knees. You can try to outsource the convolution part to different instances of pd with [pd~] but I think it makes much more sense to do it with tools that are better suited for this task. jconvolver comes to mind if you're using jack.
good luck with your project!

(edit: grammar)

github/gitlab is actually well suited for something like this. You could simply create a readme like this: https://github.com/olilarkin/awesome-musicdsp or this: https://github.com/nodiscc/awesome-linuxaudio. Others can contribute, create issues etc.

great!

pushed an update to deken (v 0.3).

changes since the last version:

new objects:
pp.fft-freeze~ - a spectral freezer based on I08.pvoc.reverb.pd

pp.ladder~ - a "moog" 4th order ladder filter. I made this on out of curiosity about the "zero delay filter" design. I wouldn't recommend to use it though since we have [bob~] and cpu usage is pretty high! (except if you need a fast modulating resonant hp or bp filter for whatever reason).

pp.echo~ - an "analog" tape delay-ish delay echo effect.

pp.xycurve - draws a xy-bezier curve and reads from it. Useful for all kinds of musical gestures..

Many bugfixes and smaller changes. Be aware that some object might behave a little bit differently to the last version!

@Gabriel-Lecup check out [pd~]!

also, you should optimize your system for audio if you haven't:
https://wiki.linuxaudio.org/wiki/system_configuration
Now this is a little bit off topic, you don't have to follow all the steps from the link above, but I highly recommend to install rtirq-init (https://github.com/rncbc/rtirq ) and indicator-cpufreq (http://manpages.ubuntu.com/manpages/focal/man1/indicator-cpufreq.1.html)

@whale-av well, sort of... it is nowhere documented that you can mess up a working patch with two concatenated delay lines simply because you give one of the delwrites~ a new argument.

@jameslo ohoh, you stumbled across something here...

first, @lacuna is not exactly right, the delay lines give you one sample delay as expected since the blocksize in the subpatch is 1.

so what is wrong with the patch?
here is an example:
working.pd
not_working.pd
spot the difference....... right, there is none!
The only difference between these two patches is that i created the "delwrite~/delread~ phase2Delay" after "phase1Delay" in the working example. (And i assume you created the "phase1Delay" after "phase2Delay" in the patch you shared)
Pd sorts the dsp processing of the delay lines in the order of creation. You can do the execution order thing to get it right:
execorder.pd
..but you should complain about this in the pd-mailing list because this strange behavior of pd is not properly documented anywhere it seems.

by the way, the working patch generates some very nice psychedelic mandalas when you feed it with an impulse generator : )

@jameslo delwrite~, delread~ is quite sufficient.