Nope.

It's not one block, but until the end of the current block.

The error changes with each reset of the phasor input, so the clicks sound different each time, since they last for a different number of samples. Because the control-rate message doesn't happen until the end of the audio block, the signal has a few samples of +~ before the message arrives.

I'm confident I can solve this.

Cheers,

PS I didn't CC you directly.

Lone Shark releases:

Light Vessel Automatic available now on 12" vinyl.

Build Your Wings on the Way Down, the new digital album available @ http://scifirecords.co.uk/releases
Earthlings compilation is out now @ http://www.pyramidtransmissions.com

Ninja Jamm - the revolutionary music remix app for iOS and Android: http://www.ninjajamm.com/

Gemnotes-0.2: Live music notation for Pure Data, and Metastudio 5 live composition and improvisation suite, available at http://sharktracks.co.uk/puredata

On Thursday, 29 September 2016, 13:40, IOhannes m zmoelnig <zmoelnig@iem.at> wrote:

On 2016-09-29 12:00, Ed Kelly via Pd-dev wrote:

> Hey list,I'm tearing my hair out trying to re-write the wrap~ object, so that it doesn't wrap instantly but waits until the end of the audio block to wrap~ the signal. I hope you understand.

no (nto trying very hard though).

i'm pretty confident that you are trying to solve the wrong problem.

if you want to delay the signal coming out of [wrap~] for one block, use
[delread~]/[delwrite~].
it's all there. nothing's needed to be coded. (using a delay of "0" and
order-forcing to make sure that [delwrite~] is handled after [delread~]
will give you exactly one block of delay).

if you want to do something else, then it's probably borked by design :-)

gmasdr
IOhannes

PS: please do not CC me. please only reply to a single mailinglist.

_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev