by Unknown » Tue Mar 29, 2022 5:33 am
Thank you very much for doing that. I am looking forward to test it if it works as I need.
It is very important for me that the firing order of these events is the following:
- playbackState 'completeEnd';
- playbackState 'stop' or playbackEnd (currently, these two are almost the same anyway).
In another words, I need to know the real reason for the payback end in the playbackState 'stop' or playbackEnd events, not after them.
Maybe it would be better if you just added one new property, lets call it endReason or reasonForEnd or something like that, which would be available in the playbackState 'stop' or playbackEnd events, with the following possible values:
1. playback of track is finished because end of track is reached;
2. playback of track is finished because end of track is reached and no other track is going to be played;
3. playback of track is finished because user presses Stop, Next or Previous button, or there's any other reason for stopping playback.
And maybe that third state could be separated to these individual cases:
3. because of Stop (the old OnStop event);
4. because of Next;
5. because of Previous;
6. because of any other reason.
Many of these states could be checked out within the existing events like trackSkipped and by testing some existing properties like isPlaying, but for scripters it would be much simpler and better to have all info in just one place.
One more thing to consider. Is it really necessary that we have getCurrentTrack in the playbackState 'stop' and playbackEnd events as the next file that is in the list? The old SDB.Player.CurrentSong in OnPlaybackEnd, OnTrackEnd and onStop showed the SDB.Player.CurrentSong that is just finished playback, not the next one.
Here is what I get with MM5 after double click on Track1, playing it and pressing stop on Track2 before its end:
- playbackState 'trackChanged' - isPlaying = false, getCurrentTrack = Track1, getNextTrack = Track2;
- playbackState 'play' - isPlaying = true, getCurrentTrack = Track1, getNextTrack = Track2;
- playbackState 'stop' - isPlaying = true, getCurrentTrack = Track2, getNextTrack = Track3
-> MM4 didn't have playbackState 'stop', but it had OnTrackEnd instead, which had CurrentSong = Track1;
- playbackend - isPlaying = true, getCurrentTrack = Track2, getNextTrack = Track3
-> in OnPlaybackEnd event of MM4 that still would be CurrentSong = Track1;
- playbackState 'trackChanged' - isPlaying = true, getCurrentTrack = Track2, getNextTrack = Track3;
- playbackState 'play' - isPlaying = true, getCurrentTrack = Track2, getNextTrack = Track3;
- playbackState 'stop' - isPlaying = false, getCurrentTrack = Track2, getNextTrack = Track3;
- playbackend - isPlaying = false, getCurrentTrack = Track2, getNextTrack = Track3.
As you could see:
1. the current playbackState 'stop' and playbackend have the same values for isPlaying, getCurrentTrack and getNextTrack, so one of these events is redundant;
2. the getCurrentTrack actually returns the next file in playbackState 'stop' and playbackend if there is no interruption in playback and there exists other track in the list that follows;
3. the getCurrentTrack returns the real current file (i.e. the same as it is in the previous playbackState 'play' event) in playbackState 'stop' and playbackend if user presses Stop or the track reached the end and no other track is going to be played.
Well, such behavior is in fact helping me to determine if the playback reached the end, but without your new event I cannot know what is the reason for that end.
Since the playbackState 'stop' and playbackend events are almost the same, I suggest that you make the first one compatible with the old OnTrackEnd event, i.e. the getCurrentTrack in playbackState 'stop' should return the file that just finished play, not the next one. And playbackend could stay as it is now.
Thank you very much for doing that. I am looking forward to test it if it works as I need.
It is very important for me that the firing order of these events is the following:
- playbackState 'completeEnd';
- playbackState 'stop' or playbackEnd (currently, these two are almost the same anyway).
In another words, I need to know the real reason for the payback end in the playbackState 'stop' or playbackEnd events, not after them.
Maybe it would be better if you just added one new property, lets call it endReason or reasonForEnd or something like that, which would be available in the playbackState 'stop' or playbackEnd events, with the following possible values:
1. playback of track is finished because end of track is reached;
2. playback of track is finished because end of track is reached and no other track is going to be played;
3. playback of track is finished because user presses Stop, Next or Previous button, or there's any other reason for stopping playback.
And maybe that third state could be separated to these individual cases:
3. because of Stop (the old OnStop event);
4. because of Next;
5. because of Previous;
6. because of any other reason.
Many of these states could be checked out within the existing events like trackSkipped and by testing some existing properties like isPlaying, but for scripters it would be much simpler and better to have all info in just one place.
One more thing to consider. Is it really necessary that we have getCurrentTrack in the playbackState 'stop' and playbackEnd events as the next file that is in the list? The old SDB.Player.CurrentSong in OnPlaybackEnd, OnTrackEnd and onStop showed the SDB.Player.CurrentSong that is just finished playback, not the next one.
Here is what I get with MM5 after double click on Track1, playing it and pressing stop on Track2 before its end:
- playbackState 'trackChanged' - isPlaying = false, getCurrentTrack = Track1, getNextTrack = Track2;
- playbackState 'play' - isPlaying = true, getCurrentTrack = Track1, getNextTrack = Track2;
- playbackState 'stop' - isPlaying = true, getCurrentTrack = Track2, getNextTrack = Track3
-> MM4 didn't have playbackState 'stop', but it had OnTrackEnd instead, which had CurrentSong = Track1;
- playbackend - isPlaying = true, getCurrentTrack = Track2, getNextTrack = Track3
-> in OnPlaybackEnd event of MM4 that still would be CurrentSong = Track1;
- playbackState 'trackChanged' - isPlaying = true, getCurrentTrack = Track2, getNextTrack = Track3;
- playbackState 'play' - isPlaying = true, getCurrentTrack = Track2, getNextTrack = Track3;
- playbackState 'stop' - isPlaying = false, getCurrentTrack = Track2, getNextTrack = Track3;
- playbackend - isPlaying = false, getCurrentTrack = Track2, getNextTrack = Track3.
As you could see:
1. the current playbackState 'stop' and playbackend have the same values for isPlaying, getCurrentTrack and getNextTrack, so one of these events is redundant;
2. the getCurrentTrack actually returns the next file in playbackState 'stop' and playbackend if there is no interruption in playback and there exists other track in the list that follows;
3. the getCurrentTrack returns the real current file (i.e. the same as it is in the previous playbackState 'play' event) in playbackState 'stop' and playbackend if user presses Stop or the track reached the end and no other track is going to be played.
Well, such behavior is in fact helping me to determine if the playback reached the end, but without your new event I cannot know what is the reason for that end.
Since the playbackState 'stop' and playbackend events are almost the same, I suggest that you make the first one compatible with the old OnTrackEnd event, i.e. the getCurrentTrack in playbackState 'stop' should return the file that just finished play, not the next one. And playbackend could stay as it is now.