On Apr 26, 3:20 pm, Jerry Avins <j...@ieee.org> wrote:> On 4/26/2010 9:36 AM, Ross wrote: > > > > > On Apr 26, 12:30 pm, Rune Allnor<all...@tele.ntnu.no> wrote: > >> On 26 apr, 12:20, Ross<rossclem...@gmail.com> wrote: > > >>> "Correcting" is not going to be the right word, but here's my problem. > > >>> I would like to have a brick wall filter with no phase delay and > >>> moderate computational complexity. (Yes, I know, who wouldn't). > > >> ...so you don't know much 'bout filters, do you? > > > Can you please explain what you mean by this? I know that there are no > > brick wall filters and I believe my message made it clear that I > > wasn't expecting to be able to completely repair the signal from my > > significantly not "brick wall" filter to make it a higher performing > > *all purpose* filter. My comment about wanting a brick wall filter > > without significant delay nor excessive computational requirements was > > a tongue in check comment intended to be read as "ideally what I'd > > like is this, but since I know I won't get it, ....." > > >>> Are there any techniques or research on how to "correct" early output > >>> from a filter after there has been a sudden change from (relative) > >>> silence to signal? > > >> The initial transient is a fact of life. > > > Please note that I'm not expecting to produce, by compensating for it, > > a brick wall filter. I'm looking at a situation where I intend to > > track the frequency and magnitude of the output from the filter based > > on the assumption that it's a reasonable approximation to a sine wave. > > > If the output was an idea sine wave, which it won't be given that the > > filter is not ideal nor will the input signal be idea, then with a few > > samples I could fit a sinewave to the input with three samples or so. > > Since my input is not ideal, I'll only be able to constrain the > > frequency within a probability distribution. After a few cycles of > > input, I'll be able to constrain the frequency between upper and lower > > bounds which will be amply accurate for my needs. But, when the input > > signal goes from 0 to signal, partially due to the initial transient > > of the filter, I expect that simple methods will give me too wide a > > probability distribution for frequencies. I can apply a number of "AI" > > style techniques on the unmodified output of the filter which may > > (experiments not yet done) improve the accuracy of the prediction > > early on. However, it would be silly to reinvent wheels should there > > be research that characterises the nature of the initial transients > > from filters such that their effect on dynamic signals is well > > understood and can be predicted for non-trivial input signals. > > > Is this clearer? > > What is clear is that you don't understand the problem. I'll try to > explain. Whether digital or analog, every filter has memory elements. (I > assume that you can identify them in your particular filter. If not, > ask.) Until the contents of those memory elements settle to a repeating > cycle of values determined by a repetitive input, the output of the > filter will deviate from the naively expected. If you know enough about > the input signal to preload the memory elements (set the initial > conditions, as the math people say) you don't really need a filter. The > output of an IIR filter depends on a large number of the input samples. > The "expected" output assumes an infinite number of them. > > You have another problem. Your signal isn't bandlimited, so many of its > higher components alias into the passband. That changes what you expect > (or should expect) your output to be. > > JerryErm, I think I do understand the problem. I have done worked examples where I've (algebraically) unwrapped a trivial IIR filter into a FIR approximation which uses a large number of past samples, and understand how this affects the filter when the nature of the input signal changes. I feel that I do understand why IIR filters in real life take time to settle to a repeating cycle of values. I've inspected the initial transient for trivial data and know what it looks like. What I'm asking is if anyone has done any work or developed any methods applicable when *analysisng* filtered versions of dynamic (changing) signals. I'm trying to think of a clearer way of phrasing my question so that it can be more directly understood. But, I'm now regretting my tongue in cheek comment about brick wall filters in the first post, and I'm now concerned that in making that comment I've ruined my chance to get an answer to my question. Vladimir: Here is the real problem. Monophonic guitar (and other instruments) can be created by tracking the pitch of a digitally sampled version of the notes played by the musician and synthesising a sound which follows the played pitch, and usually uses the volume which which notes are played as a parameter in the synthesis. In certain types of these guitar synthesisers, the analysis of pitch and volume is very tightly bound with the synthesis, to reduce: 1) The time lag inherent when one device analyses the input, and sends information to a second device (usually through some sort of serial connection) which synthesises the note. 2) To avoid the unsuitable (IMHO) MIDI (Musical Instrument Digital Interface) data format which does not work well with input devices which require frequency tracking and continual refinement of tracked pitch. 3) The time lag of systems which wait until they have received enough of a played note to be reasonably confident of the pitch of a note. A bass guitar playing a low B is about 31Hz, so to wait for one whole cycle to complete is more than 32ms. I wanted to do an experiment. Not a great big experiment, but just a little quick hack personal experiment. I wanted to experiment with as close to zero lag as I could possibly get. For example, as a trivial (not real) example, imagine that I'm tracking a bass guitar, and wish to synthesise a full amplitude (ignoring playing dynamics) sawtooth wave. What I can do is have one decision procedure which decides when a note has been played. (This is a difficult problem in itself, but just for this discussion I wish to ignore it here). As soon as a note is detected, the output value is raised to 1.0 to represent the step value change at the start of a cycle of a sawtooth. In successive samples (yes I know my output in this example is not bandlimited) then I have to decrement the output sample value according to the sampling rate and the frequency being played. I intend to look into methods that will produce a continual update of the estimated frequency on a sample by sample basis, and refine and correct the output frequency. This means that the output will not be a pure sawtooth wave, particularly over the first cycle, as the refinement of the frequency estimation will warp the waveform. In this way, I wanted to look at making a tradeoff between reduced latency, with the tradeoff being distortion of the synthesised signal during the attack portion (beginning) of a played not. One common method of tracking pitch of monophonic instruments is to use a filter bank. Lowpass filters used in parallel, with the cutoff frequencies being slightly less than an octave apart, starting from less than an octave below the lowest note. If only pitched notes are played, and everything is more perfect than it will be in real life, then one filter will output the fundamental of the played note, and only the fundamental. In reality the lowest filter bank that produces a significant output will generally produce a signal close enough to a sine wave to be easily tracked. And, it will usually possible to estimate frequency several times a cycle, e.g. measuring the distance between peaks and zero crossings. Generally, once one cycle of the note is completed, pitch can be tracked very well. Good for piccolo, not so good for extended range bass guitar. However, when a note is played, the first part of the waveform is distorted by the initial transient of the filter. Simple pitch estimation techniques that don't account for this distortion would produce bad initial pitch estimates leading to considerable distortion of the initial cycle of the synthesised sound. I believe that Artificial Intelligence techniques could help interpret the output signal in the period of the initial transient. And if so, reduce the initial distortion. However, AI techniques are often (IMHO) misapplied. In that they are applied to problems where there is already a robust solution. E.g. using AI techniques for optimisation for problems that can be solved by (say) Linear Programming techniques that will guarantee an optimal solution and produce it in an acceptable time. So, my point in posting was to ask about the problem of the initial transient. I never expected there to be a solution that would repair the original signal to the point where a better all-purpose filter was created. But, I thought it might be the case that someone might say "if you're only interested in an estimate of the position of the first peak then XXY's model of filter behaviour may do this or do that". Is that more clear?
"Correcting" output of a filter
Started by ●April 26, 2010
Reply by ●April 26, 20102010-04-26
Reply by ●April 26, 20102010-04-26
On Apr 26, 4:08 pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:> Hm, it is interesting to guess. The OP is obviously not a pro although > he tries to accomplish some kind of sub audio signaling; so it should be > something very common. My first guess would be amateurish EEG or ECG.I am not a professional in DSP. For various applications I use filters designed for me by software or from cookbooks. The point of my question is whether there are known solutions to a particular problem (described in my previous post) that I would need to be aware of, or whether I am risking producing a soft computing solution to a problem that already has a hard mathematical solution. Or at least where there are tools and techniques that cannot be ignored and should form components of a soft computing solution.
Reply by ●April 26, 20102010-04-26
Ross wrote:> "Correcting" is not going to be the right word, but here's my problem. > > I would like to have a brick wall filter with no phase delay and > moderate computational complexity. (Yes, I know, who wouldn't). > > I'm actually using Butterworth lowpass filters of order 4 as designed > by Tony Fisher's web page. > > Imagine I create a 4 pole LPF, with a corner frequency of 31Hz with a > sampling rate of 44.1Khz. The filter gain is very high. On the order > of 4.77e10 or something like that. > > I've created a sample signal to feed into this. It has 30 samples of > silence, followed by a 20 Hz (non-bandlimited) sawtooth wave for 44100 > samples. > > If I filter this signal and then graph the result, it takes some time > for the filter to "get going". The first cycle has a > "concave" (looking from left to right) start from zero and climb to > first peak, rather than the slightly convex more sine-like rises later > on. Also, the height of the first peak is lower than other ones.The concavity is because it is 'trying' to make a raised sine, and would happen with just about any sharp filter and any input waveform.> Are there any techniques or research on how to "correct" early output > from a filter after there has been a sudden change from (relative) > silence to signal?I don't think you want to mess the signal up with the wrong filter, then fix it up with some kluge.> I will not be using the output of the filter in any > audio that is actually listenened to. I will only be tracking the zero > crossings and peaks of the waveform. However, I need to have an > estimate early on of the peak value of the waveform passing through.That statement just screams "matched filter" to me. This is a problem in estimation and detection with a specific known signal. Yet you're applying a solution that is appropriate for estimating and detecting a very loosely known family of signals.> Tricky given that the filter takes some time to "get going" (AKA the > filter isn't a brick wall filter).The more "brick wall" the filter is, the longer it'll take to get going. This trend will continue until you have an absolute brick wall filter, which will have an infinite delay and infinitely long ringing.> Any hints?Tell us more, and we'll help you more. How rapidly are your amplitudes changing? What's your SNR? How well known is the amplitude before hand? How accurately do you need to estimate zero crossings? Does the number of cycles in the burst change? Is it a burst, or is it a signal that starts unpredictably but then goes on for a long time? Can you get away with a less-accurate estimate initially, followed by a refinement, or must your first zero-crossing time estimate conform to the same estimate as your last? Etc. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●April 26, 20102010-04-26
On Apr 26, 5:08 pm, Tim Wescott <t...@seemywebsite.now> wrote:> Ross wrote: > > "Correcting" is not going to be the right word, but here's my problem. > > > I would like to have a brick wall filter with no phase delay and > > moderate computational complexity. (Yes, I know, who wouldn't). > > > I'm actually using Butterworth lowpass filters of order 4 as designed > > by Tony Fisher's web page. > > > Imagine I create a 4 pole LPF, with a corner frequency of 31Hz with a > > sampling rate of 44.1Khz. The filter gain is very high. On the order > > of 4.77e10 or something like that. > > > I've created a sample signal to feed into this. It has 30 samples of > > silence, followed by a 20 Hz (non-bandlimited) sawtooth wave for 44100 > > samples. > > > If I filter this signal and then graph the result, it takes some time > > for the filter to "get going". The first cycle has a > > "concave" (looking from left to right) start from zero and climb to > > first peak, rather than the slightly convex more sine-like rises later > > on. Also, the height of the first peak is lower than other ones. > > The concavity is because it is 'trying' to make a raised sine, and would > happen with just about any sharp filter and any input waveform. > > > Are there any techniques or research on how to "correct" early output > > from a filter after there has been a sudden change from (relative) > > silence to signal? > > I don't think you want to mess the signal up with the wrong filter, then > fix it up with some kluge. > > > I will not be using the output of the filter in any > > audio that is actually listenened to. I will only be tracking the zero > > crossings and peaks of the waveform. However, I need to have an > > estimate early on of the peak value of the waveform passing through. > > That statement just screams "matched filter" to me. This is a problem > in estimation and detection with a specific known signal. Yet you're > applying a solution that is appropriate for estimating and detecting a > very loosely known family of signals. > > > Tricky given that the filter takes some time to "get going" (AKA the > > filter isn't a brick wall filter). > > The more "brick wall" the filter is, the longer it'll take to get going. > This trend will continue until you have an absolute brick wall filter, > which will have an infinite delay and infinitely long ringing. > > > Any hints? > > Tell us more, and we'll help you more. How rapidly are your amplitudes > changing? What's your SNR? How well known is the amplitude before > hand? How accurately do you need to estimate zero crossings? Does the > number of cycles in the burst change? Is it a burst, or is it a signal > that starts unpredictably but then goes on for a long time? Can you get > away with a less-accurate estimate initially, followed by a refinement, > or must your first zero-crossing time estimate conform to the same > estimate as your last?SNR will be high, at least 16 bit sampling, through instrument noise may add to that. I don't know how accurately I need to estimate zero crossings. When the filter is running properly then I know from past experience that simple curve fitting around maximum, minima, and zero crossings will produce a sufficiently accurate frequency estimation. In what I was thinking to do, inaccuracy of estimation leads to distortion in the initial part of the synthesised note. I do not know what level of distortion will be audible and/or objectionable, and hence can't quantify my required accuracy. The "AI Techniques" I mention would effectively do template matching like a matched filter but templates would have to be aggressively indexed to prevent excessive computational requirements. Since this was only going to be a quick hack, and since the signal for analysis will be fairly smooth, I thought that the amplitudes of regular sampled intervals during the first significant rise in amplitude above zero combined with a decision tree might be worth a first shot. The decision tree would produce the initial estimates of frequency. Multiple decision trees for different times during the initial part of the note would be used (and easy to produce - the actual frequency of the attack can be reverse engineered by the easy to track later parts of the notes meaning training data can be produced in bulk with ease.
Reply by ●April 26, 20102010-04-26
On 26/04/2010 17:02, Ross wrote: ..> Vladimir: Here is the real problem. > > Monophonic guitar (and other instruments) can be created by tracking > the pitch of a digitally sampled version of the notes played by the > musician and synthesising a sound which follows the played pitch, and > usually uses the volume which which notes are played as a parameter in > the synthesis...> I wanted to do an experiment. Not a great big experiment, but just a > little quick hack personal experiment. I wanted to experiment with as > close to zero lag as I could possibly get.The problem is that at the instant of plucking the string, the pitch actually is not in any sense already there - the spectrum is mostly chaotic (the basis of the classic Karplus-Strong waveguide model). Never mind the filter - the string itself takes a measurable time to 'settle" into the target pitch. It may not seem a long time to the human ear, but to a dsp process it amounts to a lot of samples. Shorten the response time and the procedure involves more and more guesswork; and tracking zero-crossings will likely give you more wrong than right answers. The high harmonics will also tend to settle/converge before the fundamental; which is at least in part why many trackers give octave errors when trying to reduce latency that bit too much. I can't cite references offhand, but the Kalman Filter is widely used in guitar pitch trackers; well worth investigating. Richard Dobson
Reply by ●April 26, 20102010-04-26
On Apr 26, 10:25�am, Jerry Avins <j...@ieee.org> wrote:> On 4/26/2010 9:37 AM, Greg Berchin wrote: > > � �... > > > > > > > Ah, the perils of designing in the frequency domain. �It's so much easier to get > > that frequency response "just right" when you don't have to worry about the time > > domain. > > > Consider that frequency response is a steady-state concept. �That is to say, > > when you specify the response of a filter at a certain frequency, you tacitly > > assume that a signal of constant amplitude at that frequency was applied an > > infinitely long time ago, and will continue for an infinite time to come. > > > But we live in the time domain. �Signals start, stop, and change. �Those starts, > > stops, and changes trigger time-domain responses from filters. �And the > > time-domain responses can be very unattractive when the filters are designed in > > the frequency domain. �It is a fundamental give-and-take; to optimize something > > in the frequency domain almost always means to "un-optimize" something else in > > the time domain, and vice-versa. > > > So the answer to your question on how to "correct" the filter is to design the > > filter for better time domain response in the first place. �And, of course, that > > means giving up something in the frequency domain. > > What a wonderfully concise way to emphasize a simple truth! Those > paragraphs should be in the preface to every writing on filter design. > > Jerry > --I thought so too except for this part: "But we live in the time domain." I think the time domain and frequency domain are both equally valid but orthoganal ways to observe the world we live in. In any particular situation, one or the other may have an advantage but they are both fundamentally valid. Mark
Reply by ●April 26, 20102010-04-26
On 4/26/2010 9:32 AM, Mark wrote:> On Apr 26, 10:25 am, Jerry Avins<j...@ieee.org> wrote: >> On 4/26/2010 9:37 AM, Greg Berchin wrote: >> >> ... >> >> >> >> >> >>> Ah, the perils of designing in the frequency domain. It's so much easier to get >>> that frequency response "just right" when you don't have to worry about the time >>> domain. >> >>> Consider that frequency response is a steady-state concept. That is to say, >>> when you specify the response of a filter at a certain frequency, you tacitly >>> assume that a signal of constant amplitude at that frequency was applied an >>> infinitely long time ago, and will continue for an infinite time to come. >> >>> But we live in the time domain. Signals start, stop, and change. Those starts, >>> stops, and changes trigger time-domain responses from filters. And the >>> time-domain responses can be very unattractive when the filters are designed in >>> the frequency domain. It is a fundamental give-and-take; to optimize something >>> in the frequency domain almost always means to "un-optimize" something else in >>> the time domain, and vice-versa. >> >>> So the answer to your question on how to "correct" the filter is to design the >>> filter for better time domain response in the first place. And, of course, that >>> means giving up something in the frequency domain. >> >> What a wonderfully concise way to emphasize a simple truth! Those >> paragraphs should be in the preface to every writing on filter design. >> >> Jerry >> -- > I thought so too except for this part: > > "But we live in the time domain." > > I think the time domain and frequency domain are both equally valid > but orthoganal ways to observe the world we live in. > > In any particular situation, one or the other may have an advantage > but they are both fundamentally valid. > > Mark >Yes and no. The frequency domain representation of a thing is really only as valid as the time domain representation if you really do run your transform all the way back to t = -inf. Otherwise, you're only looking at an approximation of the frequency domain, the importance of which, as you said, varies by application. -- Rob Gaddi, Highland Technology Email address is currently out of order
Reply by ●April 26, 20102010-04-26
On 4/26/2010 12:07 PM, Ross wrote:> On Apr 26, 4:08 pm, Vladimir Vassilevsky<nos...@nowhere.com> wrote: >> Hm, it is interesting to guess. The OP is obviously not a pro although >> he tries to accomplish some kind of sub audio signaling; so it should be >> something very common. My first guess would be amateurish EEG or ECG. > > I am not a professional in DSP. For various applications I use filters > designed for me by software or from cookbooks. The point of my > question is whether there are known solutions to a particular problem > (described in my previous post) that I would need to be aware of, or > whether I am risking producing a soft computing solution to a problem > that already has a hard mathematical solution. Or at least where there > are tools and techniques that cannot be ignored and should form > components of a soft computing solution.Whatever you do depends strongly on the waveform you hope to track. Consider a sawtooth. It increases at steady rate from an initial value and abruptly returns to that initial value at the cycle's end. Without knowing the peak value /a priori/, there is no way to determine the period until the instant of reset, even without complications that a filter introduces. Jerry -- "I view the progress of science as ... the slow erosion of the tendency to dichotomize." --Barbara Smuts, U. Mich. �����������������������������������������������������������������������
Reply by ●April 26, 20102010-04-26
Richard Dobson wrote:> On 26/04/2010 17:02, Ross wrote: > .. >> Vladimir: Here is the real problem. >> >> Monophonic guitar (and other instruments) can be created by tracking >> the pitch of a digitally sampled version of the notes played by the >> musician and synthesising a sound which follows the played pitch, and >> usually uses the volume which which notes are played as a parameter in >> the synthesis. > .. >> I wanted to do an experiment. Not a great big experiment, but just a >> little quick hack personal experiment. I wanted to experiment with as >> close to zero lag as I could possibly get. > > > The problem is that at the instant of plucking the string, the pitch > actually is not in any sense already there - the spectrum is mostly > chaotic (the basis of the classic Karplus-Strong waveguide model). Never > mind the filter - the string itself takes a measurable time to 'settle" > into the target pitch. It may not seem a long time to the human ear, but > to a dsp process it amounts to a lot of samples. Shorten the response > time and the procedure involves more and more guesswork; and tracking > zero-crossings will likely give you more wrong than right answers. The > high harmonics will also tend to settle/converge before the fundamental; > which is at least in part why many trackers give octave errors when > trying to reduce latency that bit too much. > > I can't cite references offhand, but the Kalman Filter is widely used in > guitar pitch trackers; well worth investigating.I was thinking that a Kalman filter, or some other sort of filter whose response evolves over time after the note is first plucked, would be the way to go. But a full-blown Kalman filter isn't an easy thing to apply. My kid's student-model bass guitar doesn't show a fundamental at all on the lower notes -- the pickups respond nicely to the overtones, but take your hands of the frets and pluck the fattest string, and you don't see the fundamental. This can't help but complicate things. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●April 26, 20102010-04-26
On 4/26/2010 1:16 PM, Tim Wescott wrote: ...> My kid's student-model bass guitar doesn't show a fundamental at all on > the lower notes -- the pickups respond nicely to the overtones, but take > your hands of the frets and pluck the fattest string, and you don't see > the fundamental. This can't help but complicate things."Fundamental" is a slippery concept. Many take it loosely as the lowest frequency present, but that's inadequate. That frequency of which all other components are integer harmonics is probably correct. It is also the reciprocal of the period. It need not in fact be present in a waveform; it could be absent not only in your pick-up output, but in the string itself (although I doubt that). A simple example of a waveform whose lowest frequency is three times the reciprocal of its period is a square wave with the fundamental suppressed. It makes an interesting plot: (4/pi){sin(3t)/3 + sin(7t)/7 + sin(9t)/9 + ... } What is the fundamental of a metronome beating at 72/min.? Jerry -- "I view the progress of science as ... the slow erosion of the tendency to dichotomize." --Barbara Smuts, U. Mich. �����������������������������������������������������������������������
