Hello
I have a question about the frequency parameter of [hip~] or [lop~]. This parameter must be a float, in other words it can't be a signal (like for [vcf~]). So, do I need to add a [line] object between this frequency parameter and the controlling interface (basically a time-jumping number), for the filter doesn't click ?
Thanks a lot
-j
I read: . .
[vcf~]). So, do I need to add a [line] object between this frequency parameter and the controlling interface (basically a time-jumping number), for the filter
depends on how fast you plan to change the value (or have big jumps), in short, since I don't think [lop~] does any inernal smoothing I guess it i won't hurt.
HTH
x
Selon CK x@meta.lo-res.org:
I read: . .
[vcf~]). So, do I need to add a [line] object between this frequency parameter and the controlling interface (basically a time-jumping number),
for the filter
depends on how fast you plan to change the value (or have big jumps), in short, since I don't think [lop~] does any inernal smoothing I guess it i won't hurt.
I may want to change the cutoff very fast, with big jumps. Indeed, I'm making a new filter for a granular synthesis patch, and this filter is based on several [lop~] and [hip~] filters.
I think I will add a [line] with a variable time resolution
I may want to change the cutoff very fast, with big jumps
hmm, this is worrying then. Are there not any low-pass or high-pass filters in the latest iemlib that take signal inputs for the cutoff freqs? I'm sorry, I haven't got Pd here at work, so I can't check. But I must say I HAVE noticed clicks even using the control (ie. non signal) version of [line]. I think my block size was 64, but whatever this value is the output from [line] will always be a significant jump compared to using [line~] - unless you make the [line] change REALLY slowly of course! Good luck
Matt
-=-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org/ -=-=-=-=-=-=-=-=-=-=-=-=- ----- Original Message ----- From: julien.breval@tremplin-utc.net To: "CK" x@meta.lo-res.org Cc: pd-list@iem.at Sent: Wednesday, October 06, 2004 10:01 AM Subject: Re: [PD] [dumb] question about [lop~] and [hip~]
Selon CK x@meta.lo-res.org:
I read: . .
[vcf~]). So, do I need to add a [line] object between this frequency parameter and the controlling interface (basically a time-jumping
number),
for the filter
depends on how fast you plan to change the value (or have big jumps), in short, since I don't think [lop~] does any inernal smoothing I guess it
i
won't hurt.
I may want to change the cutoff very fast, with big jumps. Indeed, I'm
making a
new filter for a granular synthesis patch, and this filter is based on
several
[lop~] and [hip~] filters.
I think I will add a [line] with a variable time resolution
Selon matthew jones m.jones@signal.QinetiQ.com:
I may want to change the cutoff very fast, with big jumps
hmm, this is worrying then. Are there not any low-pass or high-pass filters in the latest iemlib that take signal inputs for the cutoff freqs? I'm sorry, I haven't got Pd here at work, so I can't check. But I must say I HAVE noticed clicks even using the control (ie. non signal) version of [line].
that's what I feared actually
I think my block size was 64, but whatever this value is the output from [line] will always be a significant jump compared to using [line~] - unless you make the [line] change REALLY slowly of course!
I will try to use
please ignore my previous post, I incenditally stroke the "enter" key before finishing to write it
here is the correct version
I may want to change the cutoff very fast, with big jumps
hmm, this is worrying then. Are there not any low-pass or high-pass filters in the latest iemlib that take signal inputs for the cutoff freqs? I'm sorry, I haven't got Pd
here
at work, so I can't check. But I must say I HAVE noticed clicks even
using
the control (ie. non signal) version of [line].
that's what I feared actually
I think my block size was 64, but whatever this value is the output from [line] will always be a significant jump compared to using [line~] - unless you make the [line] change REALLY slowly of course!
I will try to use [line] with a very small time grain
thanks for your help
-j
julien.breval@tremplin-utc.net wrote:
I will try to use [line] with a very small time grain
well, you cannot go beyond one blocksize (64samples=1.5ms), no matter how low you make the time grain. this will still might give you clicks.
i'd suggest using iemlib-filters. even though they (most of them ?, some of them ?) can only be controlled at a message-level, they have a built-in interpolation (time is settable) which will most probably get you rid of any clicks.
mfg.a.sdr IOhannes
Selon IOhannes m zmoelnig zmoelnig@iem.at:
i'd suggest using iemlib-filters. even though they (most of them ?, some of them ?) can only be controlled at a message-level, they have a built-in interpolation (time is settable) which will most probably get you rid of any clicks.
I saw there are lots of iemlib filters. If there's a built-in interpolation, does that mean you needn't use signal messages for controlling the parameters of the filter ?
As I need a "block" shape filter, I plan on using a low pass and a high pass filter together (the two cutoff frequencies give the "beginning" and the "end" of the block). As I want something as vertical as possible, I think I will use 10th order low pass and high pass Butterworth filters.
THanks
-j
Actually, I am making a kind of brick-shaped band pass filter, as an alternative to [vcf~] which has a triangular shape. If this kind of filter already exists in a library, I will use it but I haven't found anything yet. The first solution is to use first a series of [lop~] and to pass it into a series of [hip~]. I still have some DSP problems with all this when I change the frequencies (I got surprisingly high levels sometimes). Maybe another solution is to use a kind of narrow filter bank using some [vcf~], but it's not very easy to control as I would need lots of filters, like in FFTs. The FFT is not a good solution here either, because time precision is very important.
I may want to change the cutoff very fast, with big jumps
hmm, this is worrying then. Are there not any low-pass or high-pass filters in the latest iemlib that take signal inputs for the cutoff freqs? I'm sorry, I haven't got Pd
here
at work, so I can't check. But I must say I HAVE noticed clicks even
using
the control (ie. non signal) version of [line].
that's what I feared actually
I think my block size was 64, but whatever this value is the output from [line] will always be a significant jump compared to using [line~] - unless you make the [line] change REALLY slowly of course!
I will try to use [line] with a very small time grain
thanks for your help
-j
julien.breval@tremplin-utc.net wrote:
Actually, I am making a kind of brick-shaped band pass filter,
For true brick shape, use series higher order filters. The full iemabs lib has 2nd through 10th order butterworth and other filters available. Make your cutoff frequencies track as well.
[r audio] | | [r cf] | [/ 1.2 ] | | [hp10_butt~] | | [r cf] | [* 1.2] | | [lp10_butt~]
as an alternative to [vcf~] which has a triangular shape. If this kind of filter already exists in a library, I will use it but I haven't found anything yet. The first solution is to use first a series of [lop~] and to pass it into a series of [hip~]. I still have some DSP problems with all this when I change the frequencies (I got surprisingly high levels sometimes). Maybe another solution is to use a kind of narrow filter bank using some [vcf~], but it's not very easy to control as I would need lots of filters, like in FFTs. The FFT is not a good solution here either, because time precision is very important.
I may want to change the cutoff very fast, with big jumps
hmm, this is worrying then. Are there not any low-pass or high-pass filters in the latest iemlib that take signal inputs for the cutoff freqs? I'm sorry, I haven't got Pd
here
at work, so I can't check. But I must say I HAVE noticed clicks even
using
the control (ie. non signal) version of [line].
that's what I feared actually
I think my block size was 64, but whatever this value is the output from [line] will always be a significant jump compared to using [line~] - unless you make the [line] change REALLY slowly of course!
I will try to use [line] with a very small time grain
thanks for your help
-j
Hello
For true brick shape, use series higher order filters. The full iemabs lib has 2nd through 10th order butterworth and other filters available. Make your cutoff frequencies track as well.
[r audio] | | [r cf] | [/ 1.2 ] | | [hp10_butt~] | | [r cf] | [* 1.2] | | [lp10_butt~]
that's very similar to what I did (the only difference is that I used 2 independant cutoffs), but I can't change the "cf" fast enough (on my computer, the iem filters make an digital artefact noise when changing the cutoff too fast, which means under 30 ms -- and maybe it's completely normal). By the way the original [hip~] have similar problems (whereas [lop~] can have its cutoff changed very fast without making any noise, even if you jump from 30 Hz to 20000 Hz in 1 ms).
The only solution I have found is to use a series of this block filter (3 or 5), to change their frequencies very sporadically (as a manual parameter, for example), and to make the signal pass in the filter I want. It's not very good for saving CPU load, but it's the only solution that works perfectly at high speeds.
THanks for your help
-
CK -
IOhannes m zmoelnig -
julien.breval＠tremplin-utc.net -
Lex Ein -
matthew jones