[PD] libPd timing issue, seemingly caused by processing multiple 'ticks' of audio blocks.

[i go bananas]

We're trying to implement various sync options in an iOS libPd-based app,
and have run across a noticeable drift in the timing.  The app uses 8
'ticks' of 64 samples for faster devices, and 16 ticks for slower ones.
Basically what this means, is that messages are only being processed on
these larger multi-block boundaries of 512 or 1024 samples.  And that's not
good enough for keeping timing tight.

Of course, the first question is:  Has anyone already made a workaround to
this issue???

Or does anyone know of a way to make sure libPd processes messages with
proper timing, even with the 'ticks' value set quite high?

I have an idea for adding time delay messages to clock signals...so that
they can be sent through a [pipe] in pd to arrive at the correct time
during the block processing. But it looks quite tricky to implement, and
i'll wait to see if there is maybe a better solution first.

cheers, Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151111/fe9b5ac6/attachment.html>