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 > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
