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

Andy Farnell padawan12 at obiwannabe.co.uk
Sun Mar 11 23:44:36 CET 2012



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:

Place a [lop~ 1000] after the [vline~]

This will remove any sudden little jumps and smooth the
playback at segment boundaries. Might be good enough for rock
n roll.



On Sun, Mar 11, 2012 at 11:05:31PM +0100, João Pais wrote:
> Hello list,
> 
> continuing with a topic I started some time ago (but couldn't continue the
> discussion), I've made a simulated version of my patch to explain the
> situation. The full patch is too complex, and would need audio files to be
> sent with it.
> 
> The context is as follows:
> An audio file stored in a buffer is played in small segments in a
> forward-backward sequence. Each segment is played after the previous, with
> no gaps in time or reading point. First segment goes as 0 - 8638.86, 2nd as
> 8638.86 - 17277.7, 3rd as 17277.7 - 25916.6 , etc. All segments are
> triggered at the same pace, in this case 181.818 ms. You can see all the
> segments in the [textfile].
> Ideally, the original audio file would be reproduced with no difference to
> the original - besides the playback pointer going forward-backward.
> 
> But when playing back the segments, after the first initial moment with
> almost no problems (only the clicks when playback changes direction),
> clicks start to appear at each segment - from around sample 229K onwards.
> 
> Since I'm using [vline~], I thought that the timing of the reading point
> related to the audio blocks wouldn't be a problem. But, if you record the
> output and look at the audio file, you'll see that the clicks come from a
> out of phase moment, and then the wave continues.
> 
> My question is: am I doing something wrong with the circuit? If not, is
> there an efficient way of achieving a similar playback of a stored buffer?
> 
> I hope everything is clear. The original patch is a monster, but this
> version sums up what's happening.
> 
> Btw, in the original patch all the values are calculated in real time. But
> with the "recorded" version the audio sound just the same.
> The original audio file is 5m18s long. Will the be any round-up problems
> while calculating the segment coordinates to tabread4~?
> 
> Thanks in advance for who has the time to read this,
> 
> Joao


> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list




More information about the Pd-list mailing list