sorry, i forgot to send to the list
-------- Message transféré -------- Sujet : Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?" Date : Thu, 24 Nov 2016 10:44:05 +0100 De : cyrille henry ch@chnry.net Pour : Jonathan Wilkes jancsika@yahoo.com
Le 24/11/2016 à 03:31, Jonathan Wilkes via Pd-list a écrit :
Cyrille is doing it one go by exploiting the "bang" feature of switch~ with an [until] loop to basically "fast forward" the zeroing process by however many blocks long the buffer is. It's really clever, and I don't think it screws anything up on the outside. This is a technique I'd never thought of, and I can imagine some interesting things coming from this (though I'm not sure it's a canonical technique or incidental). There are some things to think about, like whether the [inlet~] vector is cleared or if it just keeps the last 64 samples for each iteration of the [until] loop.
My patch will not work in environment using blocksize != 64 but it could be fixed by querying current blocksize.
it could also be optimized with an increase of the subpatch blocksize during the clear process in order to reduce the until loop.
anyway, things can always be more optimized, but I don't thinks they always need to be more optimized.
I'm just talking in general about the idea of amortizing the cost of the operation across multiple blocks, which I assume is what's happening in his abstraction (or at least what's supposed to happen).
my patch is not amortizing the cost of the operation across multiple block, but this could be done easily.
Hm... In practice, how do you find Pd-l2ork's "clear" method compares to Cyrille's abstraction?
Pd-l2ork "clear" works only on pd-l2ork. my abstraction work on all pd variant. ;-)
cheers c
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list