Winamp plug-in API: notification of new track and end of playback

[emilles]

When using a Winamp-style output plug-in, is there a way to be notified (or detect) a track change?  Typically, Winamp does this by calling close() at the end of each track and open() at the start of the next.  However, MB is opening only once at the start of playback.

Also, at the end of a playlist, Winamp check isPlaying() before calling close() to prevent clipping the end of the track.  MB is not doing this either.  I could go off of the close(0 call, ut falling off the end of the playlist is indistinguishable from the user pressing the stop button, which should immediately stop the audio.

[Steven]

i think that should be ok to do - i probably wont be able to look at it until later next week

[emilles]

Thanks Steven.  A couple other minor transparency issues between Winamp and MusicBee for output plug-ins:

Pausing: MB calls setPaused(1) then reset(0), Winamp only calls setPaused(1)
Seeking while playing: MB calls reset(0), Winamp calls reset(new track pos in ms)
Seeking while paused: MB makes no calls, Winamp has same behavior as seeking while playing


Let me know if you'd like any additional details or help with Wianmp output plug-ins.  Also, I'd be happy to test anything.

[Steven]

http://musicbee.niblseed.com/V2_4/MusicBee_Exe_Patched.zip
unzip and replace the existing files.

I have done the items from the first post and tested on a couple of winamp output plugins which seem to still work as before. It would be good if you could confirm it works as expected with your plugin
For the 2nd post, do these items matter? I believe MB is using the flush command for seeking which doesnt correspond to what you are saying.

[emilles]

Steven, thanks for the quick response.  This fixes two issues for sure. End of playback is working nicely thanks to the IsPlaying calls.  Track change is much improved.  One issue there is that when I call back to MM for track metadata in the Open call, I cam getting info for the previous track.

Regarding the second point, you are correct, Flush is the callback name in the Winamp API.  What I am seeing for a seek is: Pause(1), Flush(0), Pause(0).  Since zero is passed in the flush, I need to do a lot of extra work to get the new track offset millis.  A change here is not strictly necessary since I did figure out how to get the new offset by setting a flag and checking it in the Pause callback -- asking MM for the playing offset in Flush gives the old offset so the query needs to be delayed.  It would be more efficient (and correct?) to get the new offset passed in the Flush call.

[Steven]

i should be able to address the metadata timing issue - i will post an updated version a bit later.
for the seek, MB pauses playback when seeking starts and does a Flush(0) as part of that. I am not 100% why I do that but its probably something i read somewhere and i imagine so any buffered data is flushed. When the user completes moving the seek bar, the pause is undone.
I see its not actually calling the seek command though.
So if the sequence was:
Pause
Flush(0)
user completes seek operation
Flush(new position)
Resume
if the player was already paused then the initial Pause and Flush(0) wouldnt be done (as now)
would that work for you?

[Steven]

i have re-uploaded the same link with the changes as described above

[emilles]

Thanks Steven.  I'll have a look right now.  From your description of the seek, am I correct in understanding that when the user begins seeking (grabs the slider in MB UI) that is when Pause(1), Flush(0) is called, then when user releases in new position the Pause(1) comes?  I'll see if I can confirm this behavior.  I believe there would be no harm to any output plug-ins if it was Pause(1), Flush(0), Flush(offset millis), Pause(0) as you describe.

[emilles]

Everything is working great with this latest patch.  Seek, Seek while paused, New Track, and End of Playback all working smoothly.  Thanks again.