Hey IO,

Don't worry, I got it sorted.

The right inlet of +~ receiving a control-rate object waits until the end of the block, but the signal is continuous. wrap_overshoot~ waits until the end of the audio block to synchronize with control-rate signals further down the chain.

Let's not have a debate now - all will be revealed at my paper presentation in New York in November.

See you then,
x
Ed
 
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, 16:44, IOhannes m zmoelnig <zmoelnig@iem.at> wrote:


On 2016-09-29 16:25, Ed Kelly via Pd-dev wrote:
> Because the control-rate message doesn't happen until the end of the audio block

but ain't this just wrong? iirc, the control-rate message happens before
the audio block.

anyhow, at the end of the audio block, it's too late to do audio
processing, because audio processing is already over for this block.
so it will only effect the samples of the next block.
which is much the same as delaying the signal for one block and then
applying any transformation.

the only other wish that might make some sense (from the wisher's
perspective) is, that [wrap_offshot~] is forced to be last object in the
audio queue.
this has some implications, like: what if you have two instances forced
to be the last one?
how will any objects below that forced-last object (as in: there inlet~s
are connected to the forced-last outlet~s) receive their signal in time?


i still do not understand what you are actually trying to achieve and
how. i also think that you are not entirely sure in what you are asking for.
so let's try some rubber duck debugging: if you manage to explain your
problem in simple enough words so others can understand it, we might
find a solution (or the problem/approach has evaporated)


gasdr

IOhannes

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