Re: [PD] max value of last n samples

[Roman Haefeli]

On Son, 2018-02-04 at 13:12 +, Dario Sanfilippo wrote:
> Hi, Roman. I guess that fexpr~ implies block 1 but probably a few
> other things too: 256 instantiations of the feedback loop in my
> abstractions are around 44% load whereas the same number of [fexpr~
> max($x1[0], $y[-1]*$x2[0])] are peaking at 95%.

Ah, good to know. There is no point in doing this [fexpr~] then. Thanks
for testing.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Alexandre Torres Porres]

hi, I tried only using fexpr~, here's what I got

[image: Imagem inline 1]

#N canvas 627 57 454 302 10;
#X obj 352 105 v n_\$0;
#X floatatom 352 74 5 0 0 0 - - -, f 5;
#X obj 59 117 v count_\$0;
#X obj 132 112 fexpr~ count_\$0 = $y2[-1] + 1 \; if(count_\$0 > n_\$0
\, 1 \, count_\$0);
#X obj 34 153 fexpr~ max($x1[0] \, if($x2[-1] \, $y1[-1] \, -1)) \;
;
#X obj 270 195 samphold~;
#X obj 321 154 expr~ $v1 != 1;
#X obj 34 25 noise~;
#X text 80 25 <= input;
#X text 342 249 <= output;
#X obj 270 246 else/display~;
#X text 177 73 'n' number of samples >;
#X connect 1 0 0 0;
#X connect 3 1 6 0;
#X connect 4 0 5 0;
#X connect 5 0 10 0;
#X connect 6 0 4 1;
#X connect 6 0 5 1;
#X connect 7 0 4 0;


2018-02-04 12:56 GMT-02:00 Dario Sanfilippo :

> That's certainly the way to go for efficiency: 256 rpole~ objects are
> about 10% load against 44% load of the PD-implemented counterpart.
>
> D
>
>
> On 4 February 2018 at 14:41, Matt Davey  wrote:
>
>> Really at that point, you’d have to be asking youself if there is any way
>> to use an external.
>>
>>
>> On Sunday, February 4, 2018, Dario Sanfilippo 
>> wrote:
>>
>>> Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other
>>> things too: 256 instantiations of the feedback loop in my abstractions are
>>> around 44% load whereas the same number of [fexpr~ max($x1[0],
>>> $y[-1]*$x2[0])] are peaking at 95%.
>>>
>>> D
>>>
>>>
>>> On 4 February 2018 at 12:33, Roman Haefeli  wrote:
>>>
 On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
 > There's an implementation of a peak holder in this blog post: http://
 > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
 > pure-data.

 BTW: the peak envelope part could be also implemented using fexpr~:

 [fexpr~ max($x1[0], ($y[-1]*$f2)]

 This has the advantage of not requiring a re-blocked subpatch with
 blocksize=1. However, I wonder which is computationally less expensive.
 Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster?

 Roman
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
 stinfo/pd-list


>>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Dario Sanfilippo]

That's certainly the way to go for efficiency: 256 rpole~ objects are about
10% load against 44% load of the PD-implemented counterpart.

D


On 4 February 2018 at 14:41, Matt Davey  wrote:

> Really at that point, you’d have to be asking youself if there is any way
> to use an external.
>
>
> On Sunday, February 4, 2018, Dario Sanfilippo 
> wrote:
>
>> Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other
>> things too: 256 instantiations of the feedback loop in my abstractions are
>> around 44% load whereas the same number of [fexpr~ max($x1[0],
>> $y[-1]*$x2[0])] are peaking at 95%.
>>
>> D
>>
>>
>> On 4 February 2018 at 12:33, Roman Haefeli  wrote:
>>
>>> On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
>>> > There's an implementation of a peak holder in this blog post: http://
>>> > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
>>> > pure-data.
>>>
>>> BTW: the peak envelope part could be also implemented using fexpr~:
>>>
>>> [fexpr~ max($x1[0], ($y[-1]*$f2)]
>>>
>>> This has the advantage of not requiring a re-blocked subpatch with
>>> blocksize=1. However, I wonder which is computationally less expensive.
>>> Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster?
>>>
>>> Roman
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>>> stinfo/pd-list
>>>
>>>
>>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Matt Davey]

Really at that point, you’d have to be asking youself if there is any way
to use an external.

On Sunday, February 4, 2018, Dario Sanfilippo 
wrote:

> Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other
> things too: 256 instantiations of the feedback loop in my abstractions are
> around 44% load whereas the same number of [fexpr~ max($x1[0],
> $y[-1]*$x2[0])] are peaking at 95%.
>
> D
>
>
> On 4 February 2018 at 12:33, Roman Haefeli  wrote:
>
>> On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
>> > There's an implementation of a peak holder in this blog post: http://
>> > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
>> > pure-data.
>>
>> BTW: the peak envelope part could be also implemented using fexpr~:
>>
>> [fexpr~ max($x1[0], ($y[-1]*$f2)]
>>
>> This has the advantage of not requiring a re-blocked subpatch with
>> blocksize=1. However, I wonder which is computationally less expensive.
>> Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster?
>>
>> Roman
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Dario Sanfilippo]

Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other
things too: 256 instantiations of the feedback loop in my abstractions are
around 44% load whereas the same number of [fexpr~ max($x1[0],
$y[-1]*$x2[0])] are peaking at 95%.

D


On 4 February 2018 at 12:33, Roman Haefeli  wrote:

> On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
> > There's an implementation of a peak holder in this blog post: http://
> > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
> > pure-data.
>
> BTW: the peak envelope part could be also implemented using fexpr~:
>
> [fexpr~ max($x1[0], ($y[-1]*$f2)]
>
> This has the advantage of not requiring a re-blocked subpatch with
> blocksize=1. However, I wonder which is computationally less expensive.
> Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster?
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Roman Haefeli]

On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
> There's an implementation of a peak holder in this blog post: http://
> dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
> pure-data. 

BTW: the peak envelope part could be also implemented using fexpr~:

[fexpr~ max($x1[0], ($y[-1]*$f2)]

This has the advantage of not requiring a re-blocked subpatch with
blocksize=1. However, I wonder which is computationally less expensive.
Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster?

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Roman Haefeli]

On Sam, 2018-02-03 at 12:42 +, Dario Sanfilippo wrote:
> I see what you mean, Roman. So you'd need the N-size block to be
> processed beforehand, which would imply an N-size delay in the
> output, is that right? 

Actually, your peak holder implementation does the job well for me. I
was (and am) still curious, though, how to implement what I initially
asked for which is apparently called 'sliding window maximum' [1].

What I like about your implementation is that you managed to start a
timer when a peak is detected and you do that in the signal domain. 

> I haven't thought of it, no idea whether that could be achieved by
> changing the feedback period in the peak holder and/or adding a delay
> in the input. Maybe I'll try something later.

If you're curious, that's fine, but it's not necessary to spend more
time for my case. I'm happy with your peak holder ;-)

Roman

[1] https://articles.leetcode.com/sliding-window-maximum/


> Cheers,
> Dario
> 
> On 3 February 2018 at 09:33, Roman Haefeli 
> wrote:
> > On Sam, 2018-02-03 at 02:47 +, Dario Sanfilippo wrote:
> > > Thanks, Roman.
> > >
> > > On 2 February 2018 at 21:28, Roman Haefeli 
> > > wrote:
> > > > On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
> > > > > There's an implementation of a peak holder in this blog
> > > > post: http://
> > > > > dariosanfilippo.tumblr.com/post/162523174771/lookahead-
> > limiting-
> > > > in-
> > > > > pure-data. I remember testing it but please let me know if
> > you
> > > > find a
> > > > > bug.
> > > >
> > > > Very nice write up. Thanks for sharing.
> > > >
> > > > > The current peak is replaced to whatever the input is after a
> > > > desired
> > > > > time, and the counter is reset whenever a new peak is found.
> > It
> > > > > should be easy to change it so that the peak is reset
> > > > periodically.
> > > >
> > > > It's not exactly equivalent with what I've asked, since your
> > > > implementation only takes new peaks into account after the hold
> > > > period
> > > > has ended. 
> > > Perhaps my wording in the previous email was confusing: what
> > happens
> > > is that every new peak will update the output immediately, and
> > > whenever that happens the countdown starts so that, should no
> > other
> > > peak be detected after that time, the output will be set to
> > whatever
> > > the input is in that moment.
> > >  
> > > > Assume an input signal consisting of a series of 1-sample
> > > > impulses with a period that is slightly lower than the hold
> > period.
> > > > The
> > > > output signal has a gap before each second impulse. For the use
> > > > case in
> > > > your article (which is also the use case I'm interested in),
> > that
> > > > doesn't matter much, because the peak holder signal is fed to a
> > > > peak
> > > > enveloper which somewhat masks those gaps.
> > > In that case, we should expect a full-amp DC out of the peak
> > holder
> > > for the impulses are faster than the hold time, and that's what
> > we
> > > actually get:
> > 
> > 
> > Yes, correct. If the peaks  reach the same level or are higher than
> > the
> > ones before, then the hold period is prolonged. But when they have
> > less
> > amplitude than the ones before, gaps appear. See:
> > 
> > https://netpd.org/~roman/tmp/peakholder_gaps.png
> > 
> > With a true max(x[0-(-N)], a downward stairway would appear and
> > there
> > wouldn't be any gaps. 
> > 
> > As I said, that is only small difference and for the purpose of a
> > look-
> > ahead limiter it probably doesn't matter that much.
> > 
> > Roman
> > 
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/l
> > istinfo/pd-list
> > 

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Dario Sanfilippo]

I see what you mean, Roman. So you'd need the N-size block to be processed
beforehand, which would imply an N-size delay in the output, is that right?
I haven't thought of it, no idea whether that could be achieved by changing
the feedback period in the peak holder and/or adding a delay in the input.
Maybe I'll try something later.

Cheers,
Dario

On 3 February 2018 at 09:33, Roman Haefeli  wrote:

> On Sam, 2018-02-03 at 02:47 +, Dario Sanfilippo wrote:
> > Thanks, Roman.
> >
> > On 2 February 2018 at 21:28, Roman Haefeli 
> > wrote:
> > > On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
> > > > There's an implementation of a peak holder in this blog
> > > post: http://
> > > > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-
> > > in-
> > > > pure-data. I remember testing it but please let me know if you
> > > find a
> > > > bug.
> > >
> > > Very nice write up. Thanks for sharing.
> > >
> > > > The current peak is replaced to whatever the input is after a
> > > desired
> > > > time, and the counter is reset whenever a new peak is found. It
> > > > should be easy to change it so that the peak is reset
> > > periodically.
> > >
> > > It's not exactly equivalent with what I've asked, since your
> > > implementation only takes new peaks into account after the hold
> > > period
> > > has ended.
> > Perhaps my wording in the previous email was confusing: what happens
> > is that every new peak will update the output immediately, and
> > whenever that happens the countdown starts so that, should no other
> > peak be detected after that time, the output will be set to whatever
> > the input is in that moment.
> >
> > > Assume an input signal consisting of a series of 1-sample
> > > impulses with a period that is slightly lower than the hold period.
> > > The
> > > output signal has a gap before each second impulse. For the use
> > > case in
> > > your article (which is also the use case I'm interested in), that
> > > doesn't matter much, because the peak holder signal is fed to a
> > > peak
> > > enveloper which somewhat masks those gaps.
> > In that case, we should expect a full-amp DC out of the peak holder
> > for the impulses are faster than the hold time, and that's what we
> > actually get:
>
>
> Yes, correct. If the peaks  reach the same level or are higher than the
> ones before, then the hold period is prolonged. But when they have less
> amplitude than the ones before, gaps appear. See:
>
> https://netpd.org/~roman/tmp/peakholder_gaps.png
>
> With a true max(x[0-(-N)], a downward stairway would appear and there
> wouldn't be any gaps.
>
> As I said, that is only small difference and for the purpose of a look-
> ahead limiter it probably doesn't matter that much.
>
> Roman
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Roman Haefeli]

On Sam, 2018-02-03 at 02:47 +, Dario Sanfilippo wrote:
> Thanks, Roman.
> 
> On 2 February 2018 at 21:28, Roman Haefeli 
> wrote:
> > On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
> > > There's an implementation of a peak holder in this blog
> > post: http://
> > > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-
> > in-
> > > pure-data. I remember testing it but please let me know if you
> > find a
> > > bug.
> > 
> > Very nice write up. Thanks for sharing.
> > 
> > > The current peak is replaced to whatever the input is after a
> > desired
> > > time, and the counter is reset whenever a new peak is found. It
> > > should be easy to change it so that the peak is reset
> > periodically.
> > 
> > It's not exactly equivalent with what I've asked, since your
> > implementation only takes new peaks into account after the hold
> > period
> > has ended. 
> Perhaps my wording in the previous email was confusing: what happens
> is that every new peak will update the output immediately, and
> whenever that happens the countdown starts so that, should no other
> peak be detected after that time, the output will be set to whatever
> the input is in that moment.
>  
> > Assume an input signal consisting of a series of 1-sample
> > impulses with a period that is slightly lower than the hold period.
> > The
> > output signal has a gap before each second impulse. For the use
> > case in
> > your article (which is also the use case I'm interested in), that
> > doesn't matter much, because the peak holder signal is fed to a
> > peak
> > enveloper which somewhat masks those gaps.
> In that case, we should expect a full-amp DC out of the peak holder
> for the impulses are faster than the hold time, and that's what we
> actually get:


Yes, correct. If the peaks  reach the same level or are higher than the
ones before, then the hold period is prolonged. But when they have less
amplitude than the ones before, gaps appear. See:

https://netpd.org/~roman/tmp/peakholder_gaps.png

With a true max(x[0-(-N)], a downward stairway would appear and there
wouldn't be any gaps. 

As I said, that is only small difference and for the purpose of a look-
ahead limiter it probably doesn't matter that much.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Dario Sanfilippo]

Thanks, Roman.

On 2 February 2018 at 21:28, Roman Haefeli  wrote:

> On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
> > There's an implementation of a peak holder in this blog post: http://
> > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
> > pure-data. I remember testing it but please let me know if you find a
> > bug.
>
> Very nice write up. Thanks for sharing.
>
> > The current peak is replaced to whatever the input is after a desired
> > time, and the counter is reset whenever a new peak is found. It
> > should be easy to change it so that the peak is reset periodically.
>
> It's not exactly equivalent with what I've asked, since your
> implementation only takes new peaks into account after the hold period
> has ended.


​Perhaps my wording ​in the previous email was confusing: what happens is
that every new peak will update the output immediately, and whenever that
happens the countdown starts so that, should no other peak be detected
after that time, the output will be set to whatever the input is in that
moment.


> Assume an input signal consisting of a series of 1-sample
> impulses with a period that is slightly lower than the hold period. The
> output signal has a gap before each second impulse. For the use case in
> your article (which is also the use case I'm interested in), that
> doesn't matter much, because the peak holder signal is fed to a peak
> enveloper which somewhat masks those gaps.
>

​In that case, we should expect a full-amp DC​ out of the peak holder for
the impulses are faster than the hold time, and that's what we actually get:

[image: Inline images 2]

So the peak envelope is only used to transition from the peak to the
non-peak value exponentially.



>
> I'm going to use your implementation for peak holding. Thanks!
>
> Roman
>

​Sure, you're welcome. I hope that this makes more sense.

Dario​



>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Alexandre Torres Porres]

check [pd [fexpr~] Examples] in the help file of expr~ :)



[image: Imagem inline 1]

2018-02-02 13:59 GMT-02:00 Roman Haefeli :

> On Fre, 2018-02-02 at 16:30 +0100, tim vets wrote:
> > is this any good?
> > [ fexpr~ if($x1[0]>$y1[-1], $x1[0], $y1[-1]) ]
>
> This will never return from the highest value ever experienced. I
> really need the output to return after N samples.
>
> > not sure how to reset it though...
>
> Exactly.
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Roman Haefeli]

On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
> There's an implementation of a peak holder in this blog post: http://
> dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
> pure-data. I remember testing it but please let me know if you find a
> bug.

Very nice write up. Thanks for sharing.

> The current peak is replaced to whatever the input is after a desired
> time, and the counter is reset whenever a new peak is found. It
> should be easy to change it so that the peak is reset periodically.

It's not exactly equivalent with what I've asked, since your
implementation only takes new peaks into account after the hold period
has ended. Assume an input signal consisting of a series of 1-sample
impulses with a period that is slightly lower than the hold period. The
output signal has a gap before each second impulse. For the use case in
your article (which is also the use case I'm interested in), that
doesn't matter much, because the peak holder signal is fed to a peak
enveloper which somewhat masks those gaps.

I'm going to use your implementation for peak holding. Thanks!

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Dario Sanfilippo]

There's an implementation of a peak holder in this blog post:
http://dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-pure-data.
I remember testing it but please let me know if you find a bug.

The current peak is replaced to whatever the input is after a desired time,
and the counter is reset whenever a new peak is found. It should be easy to
change it so that the peak is reset periodically.

I hope it helps.

Dario


On 2 February 2018 at 13:52, Roman Haefeli  wrote:

> Hey all
>
> Can this be done in vanilla? I'd like to output the maximum value of
> the last N input samples in the signal domain. Ideally N would be
> adjustable.
>
> It bugs my mind, but I can't think of a solution for this simply
> problem.
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Miller Puckette]

If you need this as a mesage, you can continually stuff the signal into an
array and use array max (which can be set to look at a subinterval of the
array.)  You can use an array as a circular buffer by always maintaining two
write pointers into the same array - whichever one is in front at any time
is at the head of a contiguous strip of past samples.

I don't know any way to get the value out as a signal (something for
me to think about)...

cheers
Miller

On Fri, Feb 02, 2018 at 04:59:30PM +0100, Roman Haefeli wrote:
> On Fre, 2018-02-02 at 16:30 +0100, tim vets wrote:
> > is this any good?
> > [ fexpr~ if($x1[0]>$y1[-1], $x1[0], $y1[-1]) ]
> 
> This will never return from the highest value ever experienced. I
> really need the output to return after N samples.
> 
> > not sure how to reset it though...
> 
> Exactly.
> 
> Roman



> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Roman Haefeli]

On Fre, 2018-02-02 at 23:27 +0900, Matt Davey wrote:
> i did something like that with a bang~ just triggering a counter to
> read samples from tabsend~, but not very efficient, of course. 

I don't mind converting to message and then back to signal. I did that
a few times, too. But I believe you'll be one block behind then, won't
you? You can't process a block of audio, do messages and then process a
block of audio all within one single block, or am I missing something? 

Maybe you can by bang~ing a switch~ed subpatch?

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Roman Haefeli]

On Fre, 2018-02-02 at 16:30 +0100, tim vets wrote:
> is this any good?
> [ fexpr~ if($x1[0]>$y1[-1], $x1[0], $y1[-1]) ]

This will never return from the highest value ever experienced. I
really need the output to return after N samples.

> not sure how to reset it though...

Exactly.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[tim vets]

is this any good?
[ fexpr~ if($x1[0]>$y1[-1], $x1[0], $y1[-1]) ]
not sure how to reset it though...
gr,
Tim


2018-02-02 15:58 GMT+01:00 martin brinkmann :

> On 02/02/18 14:52, Roman Haefeli wrote:
> > Can this be done in vanilla? I'd like to output the maximum value of
> > the last N input samples in the signal domain. Ideally N would be
> > adjustable.
>
> i have used cascaded samphold~ objects in a similar situation.
> though n is not exactly adjustable this way...
>
> for bigger n (> blocksize) the bang~/tabread-solution is probably better.
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[martin brinkmann]

On 02/02/18 14:52, Roman Haefeli wrote:
> Can this be done in vanilla? I'd like to output the maximum value of
> the last N input samples in the signal domain. Ideally N would be
> adjustable. 

i have used cascaded samphold~ objects in a similar situation.
though n is not exactly adjustable this way...

for bigger n (> blocksize) the bang~/tabread-solution is probably better.



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] max value of last n samples

[Roman Haefeli]

Hey all

Can this be done in vanilla? I'd like to output the maximum value of
the last N input samples in the signal domain. Ideally N would be
adjustable. 

It bugs my mind, but I can't think of a solution for this simply
problem.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list