enrique_blo

As far as I know, the only solution to make sfplay~ loop backwards is by using the preload message and creating a cue. Ok, this works fine.

But how about going to a specific point of the cue? Sending the seek message you can do this but only with the loaded file, not with the cues.

That is, if I load a file and create a cue (for example cue number 2) which is the abovementioned backwards cue, if then I use the seek message to go to a specific point of the file it works fine. But if I try to use it while playing the second cue, it would just jump to that point on the main file, not on the second cue which was being played, and continue playing.

sfplay-problems-with-backwards-playing

That's correct behavior for the 'seek' message. As the reference manual says, "The word seek, followed by a start time in milliseconds, moves to the specified position in the current file and begins playing." The position you specify refers to the time from the start of the file, not from the start of the cue.

The manual also points out that, "The seek message is intended to allow you to preview and adjust the start and end points of a cue. The seek message is always deferred to low priority." That is, it's intended to help you find the points you want to use for your cues; it's not intended for realtime jumping around. The 'preload' message is called preload because it pre-loads some of the desired sound into RAM beforehand so that it's ready to be played instantly; the 'seek' message seeks the point in the file (on disc), and thus is not necessarily as instantaneous.

One solution is to create more cues that include all the places you expect to want to jump to. But if you want to do random-access playback, jumping to locations that are decided on the fly, then you're better off loading the audio into RAM in a buffer~ object and accessing it with play~ or groove~.

sfplay~ problems with backwards playing