i want to split a signal into high mid and low parts to process them differently and later mix them back together
also i want the 2 frequencys where the split happens to be changeable.
perfect would be a solution with which one could produce any number of different paths, but 3 should suffice.

how can this be done?

thanks

you could use a series of [hip~] [bp~] [lop~]

or for greater flexibility and experimentalist vibe, opt to enter the world of FFT... http://pd-tutorial.com/english/ch03s08.html

with filters there is the question how to tune them right so that as an example:
a 2 way split into low and high, using lop and hip (i would prefer the higher Q filters from iemlib) has no gain or loss at the split frequency
which using lop~ 500; hip~ 500 should have

my current idea was this 2 split approach using it 2 times which would lead to 3 channels

thought about fft too but it would have high step sizes at lower frequencys and would be hard to control right... especially if you want to make it work for different sample rates

for using bp one would need an equal notch filter where
bp(signal)+notch(signal) ~= signal
i would love to get my hands onto such a vc pair bp/notch but cant find even a notch in extended

Have you tried [bsaylor/svf~] ?

You could fake a notch like this:

[inlet~]
|\
| \
| [vcf~]
| |
[-~ ]

saturno: couldn't figure out how to use svf the right way. it just confuses me
maelstorm: try sending a noise~ into this :/

Well, the graphs in the attached seem to show that it works. Anyway, you could also use a low-pass/high-pass filter combo.

http://www.pdpatchrepo.info/hurleur/notchtest.mmb.zip

Oh, yeah. There's also [notch], which will calculate coefficients for [biquad~].

interesting you are right again.. more or less
i made a test which is nice to look at... look in the attachment
i think i'm some kind of measurement freak

my other test showed that a signal split seems good with butt/bess_hp/lp5 and vcf_hp/lp with a Q of 0.5
but these tests didn't account for amplitude-/phase-distortions which should lead to peak/notch filter like effects at the split frequency
so maybe other values could be better
but that's what i'll try to use now... drones shouldn't care much about such things

notch goes crazy at different sample rates
try it out with the H10 stuff

http://www.pdpatchrepo.info/hurleur/testing-vcf.pd

I like how you're digging into these different filters (something that I'd like to do more of myself one of these days). I have to admit, though, I'm not really sure what I'm looking at here. Why are you comb-filtering the FFT data? What exactly is that showing?

Also, keep in mind with the H10 stuff that if you change the sampling rate you also have to change the frequency range argument of [filter-graph1] accordingly. As it is with 44100 frequency range at a 44100 sampling rate, it shows it wrapping around the Nyquist frequency. If you halve the sampling rate but not the frequency argument you get a weird readout because it's wrapping Nyquist several times. But if you also halve the argument it looks the same.

Just curious, have you checked out the rjlib filters? They're built on a custom biquad made with [czero~]s and [cpole~]s. I like them a little better than the iem stuff because they don't have the weird noise you get from changing the cutoff too quickly (though they probably are a bit more cpu intensive). They're also not too difficult to modify so that all the parameters can be controlled at audio rate.

i am not comb filtering the fft data i'm interpolating/averaging it to smooth out the noise and see the actual filter response... done with the 1 block feedback delay... nice trick i made up while looking at your patch

you only have to change the frequency range if you want to see the complete space... if you are interested in a filter you can let it at 44.1khz (or even 25k) and change the samplerate to 88,2khz the filter should look (almost) the same... but it seems that [notch] is not samplerate independent. so if you double the samplerate you have to divide the cutoff-frequency by the same amount to get the same graph
but my tests showed that a lot filters react poorly and act different on different samplerates and especially if you change the samplerate

thanks i'll try to look into the rjlib filters soon

@slur said:

i am not comb filtering the fft data i'm interpolating/averaging it to smooth out the noise and see the actual filter response... done with the 1 block feedback delay... nice trick i made up while looking at your patch

I get a pretty ugly readout when I run your patch as is. It basically looks like a stream of running peaks, which I thought was a result of the FFT comb-filtering itself. But after looking at it again, the delay lines were shorter than the block size in the [pd fft] patches. After raising them, I get what I think you're seeing. Which, I must say, is quite nice! I don't understand why you're getting away with the short delay lines though?

But now I have two more questions after seeing it right. First, why are you using the [z~ 10] for the first spectrum table? It seems that if you don't use it, you get the reconstructed noise you're expecting. Also, since spectrum3 does what you expected, can you explain the difference between the two outlets of [vcf~]? I can't seem to find the documentation on that, and I don't know enough about filters to understand just by looking at the spectrums.

you only have to change the frequency range if you want to see the complete space... if you are interested in a filter you can let it at 44.1khz (or even 25k) and change the samplerate to 88,2khz the filter should look (almost) the same... but it seems that [notch] is not samplerate independent. so if you double the samplerate you have to divide the cutoff-frequency by the same amount to get the same graph
but my tests showed that a lot filters react poorly and act different on different samplerates and especially if you change the samplerate

Yep, sorry. I kind of brain-farted there. I think I just assumed your weird readouts were a result of downsampling, and then confused myself . And you're right, it does appear [notch] uses a hard-coded sample rate.

interesting i thought that you always get a block delay in a delay feedback. because you always have to first read from the delayread~ to get the input for the delaywrite~. i can't imagine how you've got a shorter delay there. but to make it pd-weirdness-proof one should set the delay time to 1000*blocksize/samplerate

the z~ 10 is just to simulate a phase distortion which might happen if i send one or the other part of the signal through some kind of effect or whatever. i didn't test amplitude distortion (overdrive) might give an interesting result too. the result from the z~ 10 happens because at the -~ only parts of the signal get subtracted because of phase shift. as you can see the output of the vcf has a soft peak but the resulting notch is sharp. this is usually cancelled out if you +~ it directly back together.

do a H10 on both outputs.... then you know what i know

self confusion is confusingly confusing.
next time confuse someone else.
but not me!

@slur said:

interesting i thought that you always get a block delay in a delay feedback. because you always have to first read from the delayread~ to get the input for the delaywrite~. i can't imagine how you've got a shorter delay there. but to make it pd-weirdness-proof one should set the delay time to 1000*blocksize/samplerate

I was actually referring to the buffer size argument for [delread~]. You have it set to 10ms, but the blocksize is 1024, which is a little over 23ms. So a full block doesn't get recorded into the delay line.

oops running pd at insane 4*44,1khz over here so it fits with 6ms