[PD] vline~ precision under lower block sizes
msp at ucsd.edu
Mon Nov 5 01:25:24 CET 2012
short answer... the code that tries to figure out what logical time corresponds
to an individual audio sample (which vline~ needs to know as it has to
respect timestamps to sub-sample accuracy) has to count back from the
global time stamp that is only updated every 64 samples. I was mistakenly
using the block size instead of the constant 64, and also not keeping track of
the number of times vline~ is getting called within a DSP tick. It's
complicated and I hope someday to make it all work more transparently.
I'm not sure how long it will take to propagate to any comiled version...
my own 'vanilla' test compilation is at least a couple of weeks away.
On Mon, Nov 05, 2012 at 12:55:43AM +0100, João Pais wrote:
> great. What was exactly the problem? And also, how is it possible to
> get to the corrected version? Will it be part of any nightly builds?
> Will it be integrated into pd extended automatically?
> >OK... I think I have this fixed in git
> >(git clone
> >On Fri, Nov 02, 2012 at 08:29:52PM +0100, João Pais wrote:
> >>a friend noticed that vline~ behaves differently with different
> >>block sizes - namely that the smaller the block size is, the less
> >>precision it has. Besides the numbers being different with each
> >>block size, the latest values go slightly over the border of the
> >>desired range.
> >>Is this a bug, a feature, or an unavoidable behavior of the vline~
> >>Attached is a patch which explains the situation. I think it should
> >>be clearly enough explained.
> >>The bottom line is: in the patch I am working, block size is 1
> >>(sample rate 48KHz, in case it matters). Which choices are there to
> >>improve vline~'s precision, so that I get the results I am
> >>Pd-list at iem.at mailing list
> >>UNSUBSCRIBE and account-management ->
More information about the Pd-list