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....@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.da...@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 <reduz...@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@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
