Brennon Bortz

In the absence of [peak~] and [trough~] objects--coupled with my possible/probable naivete--is this the only general way to calculate (actually, estimate) the maximum and minimum amplitude values of a buffer?

peaktrough-solution

On 20 janv. 09, at 21:48, Brennon Bortz wrote:

> In the absence of [peak~] and [trough~] objects--coupled with my 

> possible/probable naivete--is this the only general way to calculate 

> (actually, estimate) the maximum and minimum amplitude values of a 

Have a look to [mxj buf.Op]. It's a java example which does have nice 

> In the absence of [peak~] and [trough~] objects--coupled with my  
> possible/probable naivete--is this the only general way to calculate  
> (actually, estimate) the maximum and minimum amplitude values of a  
> buffer?

Have a look to [mxj buf.Op]. It's a java example which does have nice  
capabilities on buffer~.

Although it doesn't handily do portions of buffers, you might want to 

have a look at [mxj buf.Op], which can get you max & min values for 

On Jan 20, 2009, at 15:48, Brennon Bortz wrote:

Although it doesn't handily do portions of buffers, you might want to  
have a look at [mxj buf.Op], which can get you max & min values for  
any buffer.

>
> In the absence of [peak~] and [trough~] objects--coupled with my  
> possible/probable naivete--is this the only general way to calculate  
> (actually, estimate) the maximum and minimum amplitude values of a  
> buffer?
>
>
>
> --
> Brennon Bortz
> Composer / Engraver / Career Student


Quote: news wrote on Tue, 20 January 2009 21:09

----------------------------------------------------

> Although it doesn't handily do portions of buffers...

Unfortunately, I must work with portions of buffers. Thanks for the idea, though! Frustratingly, my method doesn't work if these portions are smaller than 1msec...

Quote: news wrote on Tue, 20 January 2009 21:09
----------------------------------------------------
> Although it doesn't handily do portions of buffers...

Unfortunately, I must work with portions of buffers.  Thanks for the idea, though!  Frustratingly, my method doesn't work if these portions are smaller than 1msec...


On 20 janv. 09, at 22:26, Brennon Bortz wrote:

>> Although it doesn't handily do portions of buffers...

> Unfortunately, I must work with portions of buffers. Thanks for the 

> idea, though! Frustratingly, my method doesn't work if these 

The beauty of mxj* is that you have the source code which comes with 

it so you can modify them as you want. If you scroll down to the min/ 

            if (samps[i] < min) {

                min = samps[i];

                index = i;

if you change the start (int i = 0) and stop (samps.length) by 

appropriate numbers (in samples), then it will do it.

>> Although it doesn't handily do portions of buffers...
>
> Unfortunately, I must work with portions of buffers.  Thanks for the  
> idea, though!  Frustratingly, my method doesn't work if these  
> portions are smaller than 1msec...

The beauty of mxj* is that you have the source code which comes with  
it so you can modify them as you want. If you scroll down to the min/ 
max method you'll see that:

		for (int i=0;i
			if (samps[i] < min) {
				min = samps[i];
				index = i;
			}

if you change the start (int i = 0) and stop (samps.length) by  
appropriate numbers (in samples), then it will do it.

You might want to convert your selection length to samples using [mstosamps~] and then use that to drive an [uzi]. Then you can produce an offset using [+] and the selection start time (converted to samples again). Something like the example below. This method will be most accurate if you ensure that the [waveform~] snap and grid properties are set in the inspector or with the "unit samples, snap grid" messages.

Thanks everyone, these are great solutions. I was very close, but you've nailed it on the head!

Thanks everyone, these are great solutions.  I was very close, but you've nailed it on the head!


[peak~]/[trough~] solution?