Re: [music-dsp] efficient running max algorithm

2016-09-03 Thread Ross Bencina
On 3/09/2016 2:14 PM, robert bristow-johnson wrote: and in discussing iterators, says nothing about push_back() and the like. push_back(), push_front(), pop_back(), pop_front() are methods generally available on queue-like containers. from online i can get an idea, but it seems to me to

Re: [music-dsp] efficient running max algorithm

2016-09-03 Thread Evan Balster
Ross' explanation is solid. Robert: R refers to range ("delay line" size, one could say) and N refers to signal length. Clarifying about the weird linear/binary search: It's necessary to maintain O(N) complexity for processing N samples. This took me a while to grasp: If we do a backward

Re: [music-dsp] efficient running max algorithm

2016-09-03 Thread Evan Balster
Samples do not need to be processed in blocks. You can push and pop them one by one with no change in cost. R would be the parameter you're interested in---the length of the window---while N is the total number of samples processed. I describe N separate from R for various reasons. One of

Re: [music-dsp] efficient running max algorithm

2016-09-03 Thread Evan Balster
> i can't accept that at all. > especially for this mailing list. we are discussing algs that run on music and audio signals. sample rates might be as low as 22.05 kHz and might be as high as 192 kHz. if it's not streaming real-time, then the sound file might likely be 10 minutes long. or a

Re: [music-dsp] efficient running max algorithm

2016-09-03 Thread Ross Bencina
On 4/09/2016 6:27 AM, robert bristow-johnson wrote: if i were to test this out myself, i need to understand it enough to write C code (or asm code) to do it. The paper provides all of the information that you need for the basic implementation (which I recommend to start with). If there is

Re: [music-dsp] efficient running max algorithm

2016-09-03 Thread Ross Bencina
On 4/09/2016 1:42 PM, robert bristow-johnson wrote: i think the worst case ain't gonna be too much better than O(log2(windowSize)) per sample even with amortization over the block. You can think that if you like, but I don't think the worst case is that bad. I have given examples. If you

Re: [music-dsp] efficient running max algorithm

2016-09-03 Thread robert bristow-johnson
Original Message Subject: Re: [music-dsp] efficient running max algorithm From: "Evan Balster" Date: Sat, September 3, 2016 3:24 pm To: "robert bristow-johnson"

Re: [music-dsp] efficient running max algorithm

2016-09-03 Thread Ross Bencina
On 4/09/2016 2:49 AM, robert bristow-johnson wrote: sorry to have to get to the basics, but there are no *two* length parameters to this alg. there is only one. define the streaming real-time input sequence as x[n]. the length of this signal is infinite. output of running max alg is

Re: [music-dsp] efficient running max algorithm

2016-09-03 Thread robert bristow-johnson
� Original Message Subject: Re: [music-dsp] efficient running max algorithm From: "Ross Bencina" Date: Sat, September 3, 2016 10:16 pm To: r...@audioimagination.com music-dsp@music.columbia.edu