Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-14 Thread João Pais
yes, thanks. that does do the job. I usually don't work with reblocking at all, and can't look inside the code to see what can be done better. the only problem is still the clicks when the reader changes direction. I thought that it wouldn't make any clicks, because the signal would be cont

Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-14 Thread João Pais
I'm also wondering about the timing of tabread4~'s offset inlet being updated. I get fewer clicks by tossing most of the patch into a subpatch with [block~ 1]. I haven't checked really carefully, but that does seem to make it so that clicks only occur where there are gaps in the log.txt file. A

Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-14 Thread João Pais
The offset of [tabread4~] was there to avoid any reading errors when the index points get too high (the whole sample is almost 7m long). So there's not option for this, but to use only the right entry? I believe it should be possible to correct the timing issues of the offset inlet with some

Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-14 Thread Frank Barknecht
Hi, On Tue, Mar 13, 2012 at 08:01:21PM +0100, João Pais wrote: > The offset of [tabread4~] was there to avoid any reading errors when the > index points get too high (the whole sample is almost 7m long). So > there's not option for this, but to use only the right entry? I believe it should be

Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-13 Thread William Brent
> The offset of [tabread4~] was there to avoid any reading errors when the > index points get too high (the whole sample is almost 7m long). So there's > not option for this, but to use only the right entry? Seems like you should stick with your original approach using the right inlet for good ind

Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-13 Thread João Pais
Hi Andy, Joao, if the jumps are always (theoretically zero) going to be very small (no backjumps of a whole segment) then let's suggest a quick and practical fix and ignore the whole issue of sample accuracy in the control system. I take it you only need this to sound good enough, not be sample

Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-13 Thread João Pais
On Mon, Mar 12, 2012 at 11:32:44AM -0400, William Brent wrote: I'm also wondering about the timing of tabread4~'s offset inlet being updated. I get fewer clicks by tossing most of the patch into a subpatch with [block~ 1]. I haven't checked really carefully, but that does seem to make it so tha

Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-13 Thread Frank Barknecht
On Mon, Mar 12, 2012 at 11:32:44AM -0400, William Brent wrote: > I'm also wondering about the timing of tabread4~'s offset inlet being > updated. I get fewer clicks by tossing most of the patch into a > subpatch with [block~ 1]. I haven't checked really carefully, but > that does seem to make it

Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-12 Thread William Brent
Ah - very good to know, thanks! On Mon, Mar 12, 2012 at 11:43 AM, Frank Barknecht wrote: > Hi William, > > > On Mon, Mar 12, 2012 at 11:32:44AM -0400, William Brent wrote: >> Another thing is that, even though vline~ can start ramping between >> block boundaries, there's still a lower limit invol

Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-12 Thread Frank Barknecht
Hi William, On Mon, Mar 12, 2012 at 11:32:44AM -0400, William Brent wrote: > Another thing is that, even though vline~ can start ramping between > block boundaries, there's still a lower limit involved. You can see > in the attached patch that you can't get a period less than about 88 > samples

Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-12 Thread William Brent
I'm also wondering about the timing of tabread4~'s offset inlet being updated. I get fewer clicks by tossing most of the patch into a subpatch with [block~ 1]. I haven't checked really carefully, but that does seem to make it so that clicks only occur where there are gaps in the log.txt file. An

Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-12 Thread João Pais
Hi William, The first thing I'm wondering is if you want each segment to have the same number of samples. I see that the time to scrub through each segment is the same (181.818 ms), but then the length of segments in samples varies. I guess the pitch shift that happens from this isn't a proble

Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-11 Thread William Brent
Hi João, The first thing I'm wondering is if you want each segment to have the same number of samples. I see that the time to scrub through each segment is the same (181.818 ms), but then the length of segments in samples varies. I guess the pitch shift that happens from this isn't a problem? A

Re: [PD] vline~ precision, or sequentially segmented playback of a buffer

2012-03-11 Thread Andy Farnell
Joao, if the jumps are always (theoretically zero) going to be very small (no backjumps of a whole segment) then let's suggest a quick and practical fix and ignore the whole issue of sample accuracy in the control system. I take it you only need this to sound good enough, not be sample accurate