How Come When Using Some Filters...
-
- KVRAF
- 10597 posts since 13 Jun, 2004 from Alberto Balsam
On some filters when I adjust the cutoff too quickly, it starts to sound quantized like it is stopping at evenly intervined frequencies at equal time intervals, sometimes sounding like a fast arpeggiator? (sorry I'm horrible at explaining things).

-
- KVRAF
- 7317 posts since 7 Mar, 2003
-
- KVRian
- 665 posts since 7 Jan, 2003 from somewhere between 50 and 60Hz
yeh this is called "stepping", but some hosts/plugins smooth this AFAIK
-
- KVRian
- 886 posts since 2 Jun, 2005 from Hawaii
-
- KVRian
- 576 posts since 30 Jan, 2004 from Baja Texas
Think of zipper effect as a "feature," and then it's a lot of fun, sometimes.

RogerPerrin
I'm up to my old hat tricks again.
I'm up to my old hat tricks again.
-
- Banned
- 1648 posts since 11 Sep, 2005
this wouldn't happen with a "sample accurate" filter but since that makes the CPU slow down to a grind, it usually filters a certain sample block completely which makes it sound gritty like that.The Chase wrote:On some filters when I adjust the cutoff too quickly, it starts to sound quantized like it is stopping at evenly intervined frequencies at equal time intervals, sometimes sounding like a fast arpeggiator? (sorry I'm horrible at explaining things).
Which filter are you referring to?
-
- KVRAF
- 2935 posts since 14 Dec, 2003 from Edinburgh
- KVRAF
- 12615 posts since 7 Dec, 2004
the simple solution is a parameter input filter.. chase, if you explain what kind of filter it is, maybe xhip's filter might do? i could code that up in a few minutes. if it is some weirdo kind of filter though, sorry i cant help, complain to the coders :O
- KVRAF
- 12615 posts since 7 Dec, 2004
i'd like to point out also, it isnt midi's fault, this is a problem with vst. for midi messages they use a "delta" parameter that tells the plugin how many samples into a "block" the event actually takes place. for setparameter (vst parameters) there is no delta.
basically say a block is 256 samples.
the host sends all the midi events which occur during the next 256 samples with the delta, so say a midi event happens in 62 samples, it sends "midievent(whatever) + delta(62)" to the plugin.
after sending all the midi events, it sends all the vst events which happen during the block, however, it doesnt matter when the event happens, all events happening during the next 256 samples are applied in order at the start of the block (some hosts might do slightly different things, for instance fl changes the block size to fit between events.)
so if you change the cutoff from 0.6 to 0.8 smoothly between the next 256 samples, instead of doing that, the vst host will simply send a command to set the cutoff directly to 0.8, skipping over the entire smooth transistion, and not only that, but applying the value of 0.8 256 samples too early! not to mention wasting cpu power and bandwidth by sending all the events happening between the start and end of the block when they will be ignored anyway. this is equivilant to "overdraw" in 3d rasterizers where polygons in the background are drawn even when they'll be covered over top by other polygons, meaning the cpu use drawing the background ones which you cant even see is completely wasted..
you can avoid this by using midi ccs to send cutoff and other parameter changes in real time. "automation" is almost made useless because of this flaw.. i have no idea why they decided to not use delta for vst parameter events, i dont think even they do.
the point is, blame vst, not midi
also, chase, will this do?
http://xhip.cjb.net/temp/filterz.mp3
and if not, will this do?
http://xhip.cjb.net/temp/bananastand.mp3
basically say a block is 256 samples.
the host sends all the midi events which occur during the next 256 samples with the delta, so say a midi event happens in 62 samples, it sends "midievent(whatever) + delta(62)" to the plugin.
after sending all the midi events, it sends all the vst events which happen during the block, however, it doesnt matter when the event happens, all events happening during the next 256 samples are applied in order at the start of the block (some hosts might do slightly different things, for instance fl changes the block size to fit between events.)
so if you change the cutoff from 0.6 to 0.8 smoothly between the next 256 samples, instead of doing that, the vst host will simply send a command to set the cutoff directly to 0.8, skipping over the entire smooth transistion, and not only that, but applying the value of 0.8 256 samples too early! not to mention wasting cpu power and bandwidth by sending all the events happening between the start and end of the block when they will be ignored anyway. this is equivilant to "overdraw" in 3d rasterizers where polygons in the background are drawn even when they'll be covered over top by other polygons, meaning the cpu use drawing the background ones which you cant even see is completely wasted..
you can avoid this by using midi ccs to send cutoff and other parameter changes in real time. "automation" is almost made useless because of this flaw.. i have no idea why they decided to not use delta for vst parameter events, i dont think even they do.
the point is, blame vst, not midi
also, chase, will this do?
http://xhip.cjb.net/temp/filterz.mp3
and if not, will this do?
http://xhip.cjb.net/temp/bananastand.mp3
-
Music Engineer Music Engineer https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=15959
- KVRAF
- 4388 posts since 8 Mar, 2004 from Berlin, Germany
if you have the choice between vst-parameter automation and midi-controller based automation there will be some kind of trade-off: a midi controller value will have sample accurate timing (if the plugIn make use of the delta_frames information) but is limited to a value range between 0-127 (integers). a vst-parameter on the other hand is a floating point value bewteen 0-1, so it has much higher accuracy for the value but only block-accurate timing. in both cases the plugIn can choose to smooth the incoming control-data with a simple RC-like lowpass-filter - but i can't imagine how this could be done from outside the plugIn itself.
EDIT: maybe with some kind of sub-host which uses a blocksize of one sample...
EDIT: maybe with some kind of sub-host which uses a blocksize of one sample...
