[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 <hard.off at gmail.com> 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 <sanfilippo.dario at gmail.com>
> 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 <reduzent at gmail.com> wrote:
>>
>>> On Fre, 2018-02-02 at 18:31 +0000, 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 at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>>> stinfo/pd-list
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180204/c3f3212b/attachment-0001.html>