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

William Brent william.brent at gmail.com
Mon Mar 12 16:32:44 CET 2012


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.

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 (or 44 samples for each half of the triangle wave).  Seems
like that shouldn't be affecting you though, since you're retriggering
every ~180 samples.



On Mon, Mar 12, 2012 at 5:30 AM, João Pais <jmmmpais at googlemail.com> wrote:
> 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 problem?
>
>
> that's not a problem, later there will be some pitch correction happening
> (if I also get a good enough pitch shifter, but that's another subject)
> The original audio is a "normal" sample, I just replaced it with a sine for
> the debugging.
>
>
>
>> Also, it looks like not all of the boundaries in your log.txt line up.
>>  Starting on segment 330, there are gaps now and then:
>>
>> 198694 207333 181.818;
>> 210909 219994 181.818;
>>
>> That explains the phase discontinuities (at least some).  I know this
>> is just your abstracted problem, but maybe similar unexpected gaps
>> exist in your main patch?
>
>
> :) I didn't want to write a big mail before, but don't worry about these.
> The fragments missing there are played by another player. But explaining
> much more would just look the problem I'l chasing now look more complex than
> it is.
>
> The main problem is really just the [vline~] output that should be
> continuous, but isn't.
>
>
> In fact, after writing this patch I recalled that I didn't save the output
> of the reading index into a buffer yet, to see how it looks. I'll be doing
> that later today.
>
> Thanks,
>
> João



-- 
William Brent
www.williambrent.com

“Great minds flock together”
Conflations: conversational idiom for the 21st century

www.conflations.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vline-limit.pd
Type: application/octet-stream
Size: 1418 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120312/9cbaa06e/attachment-0001.obj>


More information about the Pd-list mailing list