seek and sfplay~
I can’t believe I’m asking such a basic question, but here goes:
Sending a seek messsage into a named sfplay~ object that has preloaded files does not start playback from the seek point; in fact it does not start playback at all. The Max window states "error: sfplay~: seek: no open file". It seems preloaded files are not recognized as open files – odd, no?
I’m assuming I’d have to create a whole new bunch of preloads, one for each seek point, but that seems like a hassle. Any simpler solutions out there?
By the way, I know you can get the file name and stick a "prepend open" into the sfplay~ before it actually triggers playback, and then you can use seek; it just seems a bit redundant…
Inouk Demers schrieb:
> By the way, I know you can get the file name and stick a "prepend
> open" into the sfplay~ before it actually triggers playback, and then
> you can use seek; it just seems a bit redundant…
You can also just create a cue, followed by the cue number. That’s the
way I would do it anyway, (could always be the same cuenumber…)
Is this really the case? I can’t seek in a file that’s preloaded/cued???? I’m getting the same error as above "no open file"…
btw, I’ve also tried Stefan’s approach of a cue with the start time, but no luck. Even with the cue actually playing, if I send "preload (cue) (time)" it says "preload: no current cue"… why?
I wound-up using Inouk’s "prepend open" hack from above. The documentation is pretty clear on the function of seek ("[…] moves to the specified position in the current file […]"), so either this is a bug, or the docs should be clear on the limitations.
hm, you would think that if it was a bug, it could have been fixed since 2007.
so it is obviously intended like that and only missing in the docs. :)
you said you also dont gt it to work when using loadbang-"preload" … i believe stefan was talking about loadbang-"open".
if it doesnt work using "open", either, i would now like to ask you about the file format you are loading and on what platform.