Hi list,
it should be possible to have readsf~ loop without a gap by using a soundfile that has no discontinuities in its audio signal at the end/start, and whose length is a multiple of Pd's block size (64 by default). Yet I do get clicks when I try this. In a conversation with the helpful and great IOhannes we looked at the logic and timing of readsf~ banging its right outlet. Can it be that it bangs one block too late in order to loop seemlessly?
See attached patch.
By the way, looping playback from a table via tabplay~ does also click when using its right outlet (which is undocumented in the helpfile I happen to see right now).
Thanks for all hints! Peter
Hi,
the "sinesum" message is meant to be used together with [tabosc4~] and other 4-point interpolation objects because it automatically adds 3 guard points (1 at the beginning, 2 at the end). therefore the array size will never be a multiple of 64 and you'll get clicks when looping with [tabplay~]. it *does*, however, work properly with array sizes which are really multiples of 64 (see attached patch).
regarding [readsf~]: since the object is threaded, I'm not sure if I would even expect it to loop seemlessly...
Christof
*) the sinesum message expects a size argument that is a power of 2. "64000" will get truncated to 32768 and you get an array of size 32771.
Gesendet: Mittwoch, 01. August 2018 um 20:12 Uhr Von: "Peter P." peterparker@fastmail.com An: pd-list pd-list@iem.at Betreff: [PD] readsf~: timing of bang at outlet
Hi list,
it should be possible to have readsf~ loop without a gap by using a soundfile that has no discontinuities in its audio signal at the end/start, and whose length is a multiple of Pd's block size (64 by default). Yet I do get clicks when I try this. In a conversation with the helpful and great IOhannes we looked at the logic and timing of readsf~ banging its right outlet. Can it be that it bangs one block too late in order to loop seemlessly?
See attached patch.
By the way, looping playback from a table via tabplay~ does also click when using its right outlet (which is undocumented in the helpfile I happen to see right now).
Thanks for all hints! Peter _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 08/01/2018 08:12 PM, Peter P. wrote:
Hi list,
it should be possible to have readsf~ loop without a gap by using a soundfile that has no discontinuities in its audio signal at the end/start, and whose length is a multiple of Pd's block size (64 by default). Yet I do get clicks when I try this. In a conversation with the helpful and great IOhannes we looked at the logic and timing of readsf~ banging its right outlet. Can it be that it bangs one block too late in order to loop seemlessly?
See attached patch.
attached is a small patch that might fix the problem (by sending a bang immediately if the end-of-file has been seen and the queue is is empty)
i'm currently dizzy¹ and cannot really assess whether the change is actually correct, so it's left as an exercise to the user.
gfmadst IOhannes
¹ so i haven't done a PR