Hello,
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~
algorithms?
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 expecting?
Thanks,
João
OK... I think I have this fixed in git (git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data)
cheers Miller
On Fri, Nov 02, 2012 at 08:29:52PM +0100, João Pais wrote:
Hello,
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~ algorithms?
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 expecting?
Thanks,
João
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi,
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?
João
OK... I think I have this fixed in git (git clone
git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data)cheers Miller
On Fri, Nov 02, 2012 at 08:29:52PM +0100, João Pais wrote:
Hello,
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~ algorithms?
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 expecting?
Thanks,
João
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
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.
cheers Miller
On Mon, Nov 05, 2012 at 12:55:43AM +0100, João Pais wrote:
Hi,
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?
João
OK... I think I have this fixed in git (git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data)
cheers Miller
On Fri, Nov 02, 2012 at 08:29:52PM +0100, João Pais wrote:
Hello,
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~ algorithms?
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 expecting?
Thanks,
João
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
João Pais -
Miller Puckette