[PD] So [bang~] can't "bang" in less than 64 blocksize, huh?

Charles Z Henry czhenry at gmail.com
Mon Mar 16 20:57:14 CET 2015

On Mon, Mar 16, 2015 at 2:07 PM, IOhannes m zmölnig <zmoelnig at iem.at> wrote:
> On 03/16/2015 06:46 PM, Charles Z Henry wrote:
>> So, what if I made an external (however dangerous to patch) that does
>> trigger a float message during each perform routine?  What good is it?
> accidentally zexy's [pack~] triggers a message during each perform routine.

Ah!  I was looking for this today and I gave up when I found the
non-signal [pack] object in the vanilla code.  I couldn't remember I
had seen it in zexy.

> this was totally by mistake (or rather: because i didn't understand the
> concept of having synchronous DSP-processing separated from asynchronous
> message processing when i wrote that code)
> unfortunately some of my colleagues immediately started writing DSP-code
> (with some heavy DSP maths in message domain) relying on that behaviour,
> which makes it somewhat hard (employment wise :-)) to fix this behaviour.
> gfmrdsa
> IOhannes

I think there's some value for both, but only if you know you can't
mix the two without close inspection.

To workaround the worst part, you could lower the DEFDACBLOCKSIZE to
1, but there's still ordering issues on the messages.

Real-time dangerous, for sure, and limited usefulness.  It still seems
like a  trick to remember.

You could add the code for an "apack~" or asynchronous pack object,
and have both (not that I'm really trying to make more work for you)


> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

More information about the Pd-list mailing list