Bug on [sfplay~] while playing backwards?
Aug 31 2013 | 11:05 pm
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...
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.
- Aug 31 2013 | 11:34 pmUse a groove~ instead?
- Aug 31 2013 | 11:38 pmWhen 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.
- Sep 01 2013 | 1:05 amTo 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.
