[PD] Fwd: Re: [delwrite~], or "what Pd operations are/should be realtime?"
ch at chnry.net
Thu Nov 24 11:18:00 CET 2016
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 at chnry.net>
Pour : Jonathan Wilkes <jancsika at 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.
> 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.
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
More information about the Pd-list