maxplanck wrote:>>maxplanck wrote: >> >>.. >> >>>I'll give it a shot. >>> >>>I understand what you mean, but this may be the only dsp coding fish > > i'll > >>>ever need (so far i've been able to do everything i want to do with > > audio > >>>using the Reaktor software/visual programming language. This envelope >>>calculation is the only thing so far that i've needed to do which > > Reaktor > >>>wasn't capable of (as far as i can tell)). >> >>I don't have Reaktor, but this is a little surprising. It might be >>called "envelope follower" or something similar; a necessary building >>block of any compressor/expander. There are three possible "standard" >>forms for an envelope follower or tracker based on the tracking method: >> peak, rms or average (all over some small sliding window of samples, >>perhaps 5msecs). > > > Reaktor has an envelope follower, but the algorithm is a real time > algorithm, which is the core reason why it's less accurate than the > "absolute value then line between local maxima" method for the signals > that i'm trying to analyze. > > A real time algorithm can't know when and where the next local maxima is > going to be, it can only compute a guess for each successive sample based > on the previous samples. The "absolute value then line between local > maxima" method, being a non-real time method, knows where every local > maxima occurs, and can draw a straight line between each one and its > adjacent local maxima.*UNDEFINED TERM* --- "real time" more significant than it may appear ;)
Looking for an automated method for plotting the amplitude envelope of an audio signal
Started by ●October 18, 2007
Reply by ●October 24, 20072007-10-24
Reply by ●October 24, 20072007-10-24
>maxplanck wrote: >>>maxplanck wrote: >>> >>>.. >>> >>>>I'll give it a shot. >>>> >>>>I understand what you mean, but this may be the only dsp coding fish >> >> i'll >> >>>>ever need (so far i've been able to do everything i want to do with >> >> audio >> >>>>using the Reaktor software/visual programming language. Thisenvelope>>>>calculation is the only thing so far that i've needed to do which >> >> Reaktor >> >>>>wasn't capable of (as far as i can tell)). >>> >>>I don't have Reaktor, but this is a little surprising. It might be >>>called "envelope follower" or something similar; a necessary building >>>block of any compressor/expander. There are three possible "standard">>>forms for an envelope follower or tracker based on the tracking method:>>> peak, rms or average (all over some small sliding window of samples, >>>perhaps 5msecs). >> >> >> Reaktor has an envelope follower, but the algorithm is a real time >> algorithm, which is the core reason why it's less accurate than the >> "absolute value then line between local maxima" method for the signals >> that i'm trying to analyze. >> >> A real time algorithm can't know when and where the next local maximais>> going to be, it can only compute a guess for each successive samplebased>> on the previous samples. The "absolute value then line between local >> maxima" method, being a non-real time method, knows where every local >> maxima occurs, and can draw a straight line between each one and its >> adjacent local maxima. > > >*UNDEFINED TERM* --- "real time" > >more significant than it may appear ;)=) what's the right word to use? By "real time" i mean: for example take a "real time" algorithm f(data set). f of data set index #50 can only use the data from index #0 to 50 to generate its output (because it generates output as it receives the data one index at a time, generating an output value as it receives each data value [f(data set index #0)=.., then f(data set index #0 and #1)=..., then f(data set index #0, #1 and #2)=...., etc.] But if we take a non "real time" algorithm g(data set), g of data set index #50 can be a function of any or all elements of the data set. Does this make sense?
Reply by ●October 24, 20072007-10-24
maxplanck wrote: [*SNIP*]>>*UNDEFINED TERM* --- "real time" >> >>more significant than it may appear ;) > > > =) what's the right word to use? > > By "real time" i mean: for example take a "real time" algorithm f(data > set). f of data set index #50 can only use the data from index #0 to 50 > to generate its output (because it generates output as it receives the > data one index at a time, generating an output value as it receives each > data value [f(data set index #0)=.., then f(data set index #0 and #1)=..., > then f(data set index #0, #1 and #2)=...., etc.] > > But if we take a non "real time" algorithm g(data set), g of data set > index #50 can be a function of any or all elements of the data set. > > Does this make sense?In this case by "real time" means all analysis occurs between last sample and current sample. I'll follow up tomorrow.
Reply by ●October 25, 20072007-10-25
maxplanck wrote: ...>> *UNDEFINED TERM* --- "real time" >> >> more significant than it may appear ;) > > =) what's the right word to use? > > By "real time" i mean: for example take a "real time" algorithm f(data > set). f of data set index #50 can only use the data from index #0 to 50 > to generate its output (because it generates output as it receives the > data one index at a time, generating an output value as it receives each > data value [f(data set index #0)=.., then f(data set index #0 and #1)=..., > then f(data set index #0, #1 and #2)=...., etc.] > > But if we take a non "real time" algorithm g(data set), g of data set > index #50 can be a function of any or all elements of the data set. > > Does this make sense?How much delay can you tolerate? If you're sampling 8,000 times a second you can look ahead 20 samples if you can tolerate a 2.5 ms delay in the output. You will probably have more than that just filtering. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●October 25, 20072007-10-25
>maxplanck wrote: > > ... > >>> *UNDEFINED TERM* --- "real time" >>> >>> more significant than it may appear ;) >> >> =) what's the right word to use? >> >> By "real time" i mean: for example take a "real time" algorithm f(data >> set). f of data set index #50 can only use the data from index #0 to50>> to generate its output (because it generates output as it receives the >> data one index at a time, generating an output value as it receiveseach>> data value [f(data set index #0)=.., then f(data set index #0 and#1)=...,>> then f(data set index #0, #1 and #2)=...., etc.] >> >> But if we take a non "real time" algorithm g(data set), g of data set >> index #50 can be a function of any or all elements of the data set. >> >> Does this make sense? > >How much delay can you tolerate? If you're sampling 8,000 times a second>you can look ahead 20 samples if you can tolerate a 2.5 ms delay in the >output. You will probably have more than that just filtering. > >JerryThanks, that makes sense. I'm fairly sure that Reaktor's envelope follower does not look ahead, since the envelopes that it outputs don't appear shifted backward in time relative to the original signal. The problem with Reaktor's envelope follower is that it doesn't track the amplitude changes with enough accuracy (which makes sense as a consequence of not looking ahead).
Reply by ●October 25, 20072007-10-25
maxplanck wrote: .> > I'm fairly sure that Reaktor's envelope follower does not look ahead, > since the envelopes that it outputs don't appear shifted backward in time > relative to the original signal. The problem with Reaktor's envelope > follower is that it doesn't track the amplitude changes with enough > accuracy (which makes sense as a consequence of not looking ahead).How are you testing look-ahead? If you are saving output somewhere (to disk or whatever) Reaktor may be applying delay compensation much as VST hosts do when a plugin announces it puts a delay on the signal. To detect a delay you would need to compare signal in against signal out directly - e.g. on a software oscilloscope. As for accuracy: all your descriptions have been of a peak follower - tracking from one absolute maximum to another. But that is by no means the most likely method - if rms or average is used (both often more musically useful), narrow peaks in the source will be all but disregarded (i.e. the detected level will be below the peak). This is not "inaccurate", just acurate to a different measure (signal power rather than digital peak). You may need to read the reaKtor docs very carefully to see if they describe in detail what their E.F does. Richard Dobson
Reply by ●October 25, 20072007-10-25
Richard Owlett wrote:> PS I subscribe to "Give a man a fish, he eats for a day. Teach him to > fish ..."I subscribe to this one: "If you build a man a fire, you keep him warm for a day. If you set a man on fire, you keep him warm for life." ;-D -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536 Remember the definition of politics, "poli" from the latin means many, "tic" means blood sucking parasites.
Reply by ●October 25, 20072007-10-25
Jim Thomas wrote:> Richard Owlett wrote: > >> PS I subscribe to "Give a man a fish, he eats for a day. Teach him to >> fish ..." > > > I subscribe to this one: > > "If you build a man a fire, you keep him warm for a day. If you set a > man on fire, you keep him warm for life." >"If you show an idiot how to pray God, he will only break his forehead" (Russian noun.) VLV
Reply by ●October 25, 20072007-10-25
>maxplanck wrote: >. >> >> I'm fairly sure that Reaktor's envelope follower does not look ahead, >> since the envelopes that it outputs don't appear shifted backward intime>> relative to the original signal. The problem with Reaktor's envelope >> follower is that it doesn't track the amplitude changes with enough >> accuracy (which makes sense as a consequence of not looking ahead). > >How are you testing look-ahead? If you are saving output somewhere (to >disk or whatever) Reaktor may be applying delay compensation much as VST>hosts do when a plugin announces it puts a delay on the signal. To >detect a delay you would need to compare signal in against signal out >directly - e.g. on a software oscilloscope. > >As for accuracy: all your descriptions have been of a peak follower - >tracking from one absolute maximum to another. But that is by no means >the most likely method - if rms or average is used (both often more >musically useful), narrow peaks in the source will be all but >disregarded (i.e. the detected level will be below the peak). This is >not "inaccurate", just acurate to a different measure (signal power >rather than digital peak). > >You may need to read the reaKtor docs very carefully to see if they >describe in detail what their E.F does. > >Richard DobsonReaktor's envelope follower has a peak and a RMS mode. For the signals i'm trying to analyze, the peak mode of course produces more accurate results than RMS. There is an oscilloscope module in Reaktor, as well as a sampler module, I used both methods to compare the output from the envelope follower with the original signal. In peak mode, the envelope doesn't appear shifted backwards in time relative to the original signal. Here's why I think Reaktor's envelope follower doesn't look ahead: -the current latency is explicitly stated in its sound card control panel -this latency value does not change when the signal is run through an envelope follower -Reaktor is designed to accommodate live performance use, therefore the developers knew that latency minimization is important Does this logic sound correct?
Reply by ●October 25, 20072007-10-25
maxplanck wrote: ...> Here's why I think Reaktor's envelope follower doesn't look ahead: > > -the current latency is explicitly stated in its sound card control panel > > -this latency value does not change when the signal is run through an > envelope follower > > -Reaktor is designed to accommodate live performance use, therefore the > developers knew that latency minimization is important > > > Does this logic sound correct?Not necessarily. Knowing the maximum latency of processing, the writers might have delayed the signal an equal amount, so that whenever a process introduces its own delay, that amount could be deducted from the "arbitrarily" imposed amount. That would keep the overall delay constant and therefore unnoticed. My analog Tektronix scope can display the edge it triggers on. There is a delay line in the display signal path, but none in the trigger path. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
