Seamless switching audio files without losing place
Trying to figure out how to play an audio file, then switch to a new one (same music track but different recording) without losing my place in the song. I did figure out a way, but it seems to sometimes skip a couple of hundred ms forwards or backwards in the file when I make the switch. What I did was, when directed to switch to a new recording:
1.. save current playback time using 3rd outlet of sfplayer~. I use snapshot to get this and store as a message.
2. load new audio file into sfplayer~.
3. use "seek $1" to load up the saved playback location from step 1 above.
Does anyone know a better way that would be seamless.
seek nn nn is'nt sample accurate : Max clock domain ( min. 1 ms ).
Can make the illusion but depends of HD and load of cpu : i.e. SSD or not.
Think time domain in MSP, : buffer loaded in Ram etc.: snapshot~ makes the gate between sample(MSP) and command (Max) time domain.
I don't know your need of precision : maybe switch between 2 different sfplay~'s do the trick : access to disk, time to preload, etc.
Else go to buffer~, play~groove etc.
my 2c op zis helps
zz
THanks. I looked into groove~. Couldn't figure out how to get the current sample and cue the player with it.
Here's a basic cue point system that can be adapted for your project/ [groove~] :) Hope it helps?
Thanks, I'll take a look!
I gave you the wrong patch I'm afraid :/ The patch I've now included was adapted from Brendan McCloskey's patch that he kindly submitted to my post on creating a cue point with [groove~]. The thread is here and you might well find it useful for your needs? https://cycling74.com/forums/how-to-create-a-cue-point-with-groove-7-hours-ive-lost-on-this-today/
trying to compensate the difference of time between 2 sfplay~ , the second following the first via snapshot~.
Sometime exact, generally some ms . Strange aleas.
Interesting, depends of the needs.
zz
Hi Jamie, thanks for the correction. It looks like maybe your needs were a bit different than mine. I'm just trying to switch between two tracks of identical length (different versions of the same music track) and not randomly jump ahead or behind a few hundred ms when I do. It seems that the temporary file position in ms is stored at high enough accuracy, so not sure how it is happening. I tried some things like reducing the block size both in max and for the sound card, that did not help. Your patch looks complicated compared to what I'm doing, but I will look at it some more and see if i can use it to adapt to my purpose.
MIZU, i also thought about using 2 players. Worth a try.
If seek is not sample accurate, that still would be ok if it was only off by a ms or two. That would not be a problem at all. We are talking about maybe 100 ms though.
the difference here is from 0 - 14 ms
think too to the time to load another file in the second player before to call it with a seek
- i tryed with the same file, opened in the 2 sfplay~
funny
zzz
Hi, sorry to you both about that, I had drank some (a lot) of red wine and drifted off into a whole world of [groove~] & cue points at the sight of it (I've been working a lot on that recently). My list of things not to mix with alcohol, in future, now extends to e-bay, online dating, police and help forums.
0-14 ms is not a lot. I'm seeing much larger differences. Also, when switching from one file to the other, it can skip forward or backward. The way I'm doing it, the delay in opening up a new file would only cause a short pause, not skipping forward or backwards, I think.
Giving the bang to snapshot~ after the open command gives a "regular" 8.7 ms here.
Mystery of access to file, deal with the system and HD.
Sig iovs seems important too.
Alternative: file with nn channels, or buffers.
Godd new : a "1" to 2 sfplays~ seems sample accurate. Bad new : seek nn.nn not...
Mizu, not sure about your patch. For mine, giving bang to snapshot~ after opening file doesn't work, since loading the file resets the file index to 0.
It seems the "seek nn.nn" is not accurate. I wonder if you can create numbered cues on the fly and use those, and if it is any more accurate.
I dydn't try sflist~or playlist~ and preload cues, because "on the fly", to test the reactivity of the machine.
My interest here : "t b open" lets te bang to snapshot~ occur only when the file is opened. "seek nn" is "brutal", a preload and read needs to occur before we ear something. The 8.7 ms i can have "regularly" here can represent this time. I think it can change, depending of the system, the machine and the load of others patches.
Depends of the reactivity needs, maybe bang the snapshot~, preload a cue adding i.e. 100 ms, and banging it 100 ms later can be more accurate.
Oups, no time now to try....
zz
made it. Best accuracy +/- 1.5 ms. 100 ms needed to preload a cue augmented with 100 ms. Cue piped by 97 ms.
zz
Hi!
I am dealing with similar problem.
TODDWELTI, MIZU - any progress with this topic?
I want to make a patch with preloaded loops that have same length, and could be switched with sample-accurate syncronization.
In fact, I already made it: I used many-many sfplay~ objects for every single loop, and they all start playing at the beginning of the level. This apporach is pretty heavy for dsp.
Can I somehow use sflist~ or any other way of storing loops for that?