Bug on [sfplay~] while playing backwards?

Aug 31, 2013 at 4:05pm

Bug on [sfplay~] while playing backwards?

Any idea why the (loop 1) message on [sfplay~] doesn’t work if the sample is being played backwards?

I have it looping normally, with a 1 on the speed input inlet of [sfplay~]. The instant I send it a -1, it plays the sample once more, then it stops…

<code>

– Pasted Max Patch, click to expand. –

</code>

I can imagine there is something underneath the code for [sfplay~] that, when set for (loop 1), makes it wait for the last sample, to trigger the audio again. And since I’m playing it backwards, that last sample never comes, therefore it plays it only once, than stops.
Was just wandering if that’s an expected behaviour, or a bug.

I can’t even create the looping manually, because [sfplay~] won’t even bang when done playing if it’s set to backwards playback.

#263868
Aug 31, 2013 at 4:34pm

Use a groove~ instead?

#263870
Aug 31, 2013 at 4:38pm

When you’re working with negative speeds, you’ll need to use bidirectional cues to initiate a starting from a cue point with a negative speed. The refpages have been updated to reflect this.

#263871
Aug 31, 2013 at 6:05pm

To play the file back in reverse, you have to create a ‘preload’ cue in which you specify the cue number, the name of the file, the start point and end point (put the point that occurs earlier in the file first, even though you intend to play backward from end point to start point), then the number 1 (that’s a flag to tell sfplay~ that it should also preload some data at the end of the cue because you intend to play backward), and then the rate (-1 for backward at normal speed). So, for example, to make a cue #2 that will play starting 10 seconds into the file and reading backward to the beginning of the file, you would send the message preload 2 capture.aif 0 10000 1 -1.

#263874

You must be logged in to reply to this topic.