monitoring current track without on_play

[Teknojnky]

I am trying to figure out how would be possible/best to monitor the track change without relying on "onplay" event.

I want to be able to update captions/text/etc dynamically when cycling through track next/previous, even if player is not playing (stopped).

[Peke]

Currently that is not possible to make with scripting but Player Track Changes are watchable with plugin engine. New Events needed maybe "OnSkip"?

[Teknojnky]

I was thinking that events "OnTrackChange" and "OnTrackEnd" would be useful, I added comments here but may not be the appropriate place.

"OnSkip" could possibly be useful instead of, or in addition to "OnTrackEnd".

An "OnTrackChange" or similar event for SDB.Applications would be very useful.

This would be fired when the SDB.Player.CurrentSong changes, independantly and before "OnPlay" fires, so that scripts can easily catch track changes regardless of playback state.

Another potentially useful event, might be "OnTrackEnd", this would be fired when a track ends normal playback (but not if user/script manually activates next/previous).

This would make it easier to determine if a track finished normal playback or if user skipped/rewind playback.

So possible events to give greatest flexibility

"OnTrackChange" = any track change regardless of playback state or automatic/manual next/previous
"OnSkip" = only manual next/previous by user or script
"OnTrackEnd" or "OnPlaybackFinish" = only when full normal track is played and ends normally without user/script

[Peke]

My choice would rather new Bug than existing bug where we can track all player events.

"OnCurrentTrackChange" = only manual next/previous by user or script only if playback is Stopped
"OnTrackEnd" = only when full normal track is played and ends normally without user/script
"OnSkip" = No need for that Even in case OnTrackEnd is added due the fact that MM will fire "OnTrackEnd" -> "OnPlay" and there is no need to complicate things by adding third event "OnTrackEnd" -> "OnTrackChange" -> "OnPlay" Especially if "OnPlayCounter" event is added

Not just player specific but useful:
"OnPlayCounter" = When MM Increase Tracks playcounter by playback or when playcounter is updated on some track during Device -> MM Playcounter Sync

What do you think about this proposal?

[Teknojnky]

"OnSkip" = No need for that Even in case OnTrackEnd is added due the fact that MM will fire "OnTrackEnd" -> "OnPlay" and there is no need to complicate things by adding third event "OnTrackEnd" -> "OnTrackChange" -> "OnPlay" Especially if "OnPlayCounter" event is added

Hmm, not sure I understand..

Not just player specific but useful:
"OnPlayCounter" = When MM Increase Tracks playcounter by playback or when playcounter is updated on some track during Device -> MM Playcounter Sync

yea that could be useful

On_Play and On_Stop already exists, so ignoring that...

On_Skip and On_TrackEnd would be fine, as long as On_Skip fired even if playback is stopped.

---------------------------------------------------------------------------------------
On_Skip = any user/script initiated track change (regardless of play state)
On_TrackEnd = normal full track playback ends (but play continues with next track)
---------------------------------------------------------------------------------------

Does that look right?

[Peke]

I wanted to make things simpler so that instead of triggering three events "OnTrackEnd" -> "OnTrackChange" -> "OnPlay" instead of only two "OnTrackEnd" -> "OnPlay" Examples:
a) Normal Playback -> Player.Stop = No Events Triggered (Should we add "OnTrackEnd" Event in this case?)
b1) Normal Playback Track Ends -> "OnPlayCounter" -> "OnPlay" = where "OnPlayCounter" Triggers Event where Scripts will know that Track has ended and Play Counter is increased, "OnPlay" = New Playback has started
b2) Normal Playback Track Ends -> "OnTrackEnd" -> "OnPlay" = where "OnTrackEnd" Trigger Event will let Scripts know that Track has ended, "OnPlay" = New Playback has started
c) Normal Playback User Skips track -> "OnPlay" = New Playback has started Or it is better to use "OnTrackEnd" -> "OnPlay"?)
d) Player Stopped User Skips track -> "OnTrackChange" = User Changed Current Played Track
e) Normal Playback -> Player.Pause = No Events Triggered (Should we add "OnPause" Event in this case?)
f) Normal Playback Track Ends due to end of playlist -> "OnTrackEnd" = where "OnTrackEnd" Trigger Event will let Scripts know that Track has ended, script can easily check if it is due playlist End

Note that handling more Events with scripts would slow down Scripting Engine along with MM itself.

Hope this is more clear now?

[Teknojnky]

re: OnPlayCounter
My concern with this is, it would fire when player has not necessarily actually changed track (ie during syncs and such), so it can't be relied on as such.

[Peke]

Then using b2) is more reasonable?

EDIT: What About a)?

[SlowFoxSoftwareLTD]

It seems to me that all you need is an "OnTrackChange" event and follow the chart below to generate the appropriate events at the specified action points. This will keep the OnPlay event as is, and should not impact current scripts.
Note: The OnStop event should be generated whenever the player stops for any reason.

Code: Select all

                                                             |       Player Status       |  
                                                             +----------+----------------+
        Player Action                                        | Playing  | Stopped        |
-------------------------------------------------------------+----------+----------------|
Track Change                                                 | OnPlay   | OnTrackChange  | 
 - Next/Prev button                                           |          |                |
 - Auto play goes to next track                               |          |                |
 - Other reasons?...                                          |          |                |
-------------------------------------------------------------+----------+--------------- |
Player stops playing                                         | OnStop   |                |
 - Stop Button                                                |          |                |
 - Last Track ends                                            |          |                |
 - Next button while last track playing                       |          |                |
 - Stops when "Stop Playback after current track" is active   |          |                |
 - Other reasons?...                                          |          |                |
-------------------------------------------------------------+----------+----------------|
Player Starts playing                                        |          | OnPlay         |
-----------------------------------------------------------------------------------------+

[ZvezdanD]

Note that handling more Events with scripts would slow down Scripting Engine along with MM itself.

I am sorry for hijacking this thread, but I need to react. I think this is a very poor excuse to not implement some events which have been requested. First of all, if a scripter don't need and don't use some event, s/he could not slow down scripting engine. But if a scripter needs some event which don't exist, s/he could implement some solution which could be worse for performance then proper event handler.

Here is some example with one event which several scripters needed - it is about OnFinishAdding:
http://www.mediamonkey.com/forum/viewto ... =4&t=35656. In my script Export M3Us for Child Nodes I am recursively traversing through some tree branch and waiting for tracklist to be populated with tracks. There is no official event to let me know when MM is finished with populating tracklist, so I need to use one loop and check some parameters to see when this happens. Such approach is very CPU intensive, although I am using SDB.ProcessMessages inside of the loop. I could use the timer object instead, but anyway it occupies more CPY cycles than some proper event.

It is notable that MM developers are very difficult when they should implement some event. You could ask for some new property, or method, even some new object, but better don't try with event...

[trixmoto]

Actually I requested "OnTrackDeleting" and it was added in the very next beta build about 5 days later. It's not that they won't give you events that you ask for, it's that they won't give you them without first considering the implications and whether or not your request is actually the best way of doing something. As people are still discussing in this thread what they think the best implementation is for extra track events, why would they go ahead before there's some sort of concensus?

And back on topic, I'd have thought (c) should be "OnTrackChange" -> "OnPlay". For consistency "OnTrackChange" should always be fired when skipping, in my opinion.

[ZvezdanD]

Actually I requested "OnTrackDeleting" and it was added in the very next beta build about 5 days later.

Well, versus your one event I could specify 10 or more of them which didn't added a year or two after requests. Just take a look on the Scripting Wishlist thread.

It's not that they won't give you events that you ask for, it's that they won't give you them without first considering the implications and whether or not your request is actually the best way of doing something.

For many requests there are not any implication. If something is missing for year or two, everything which they add would be better than nothing.

As people are still discussing in this thread what they think the best implementation is for extra track events, why would they go ahead before there's some sort of concensus?

OK, I understand that. But, if some request is posted long time ago, then this is not excuse. Especially it is not an explanation that adding new events could slow down scripting engine.

[SlowFoxSoftwareLTD]

ZvezdanD, Sorry if I offended you.

First of all let me say that I am not a MediaMonkey developer. I am a very recent user, and I have "monkeyed" around with a couple of scripts.

I was just trying to contribute to the original question in this thread.

Overall I find the MediaMonkey team very responsive to questions and problem reports.
In this particular case, they are doing an outstanding job at understanding and responding to requests/requirements.
There is nothing wrong with that.

[trixmoto]

By implication I mean assessing the stability of the software and the responsiveness also. You cannot say that there are no implications unless you are a MediaMonkey developer, because you cannot assess without knowledge of the inner workings of the software. I am a senior software developer but would never try to assess the implications of anything in MediaMonkey, as I have no knowledge of it.

On this note, I don't know exactly how the event system works technically within the software. I would have thought however that for every different event (OnPlay, OnShutdown...) an overhead is added as the software would need to check for any registered events in this situation, and run them. It might be considered by the developers that allow scripts to jump in at certain points would not be good for the software's stability, and frankly this is their call.

I'm sure that all requests and considered and prioritised - there's only so many man-hours in a day!

[Teknojnky]

I've been thinking and trying clarify in my mind what I would like to accomplish and request.

I think, all that is needed for now is a simple OnTrackChange that fires whenever the player current song changes (but before playback starts). Player state can be determined by player.isplaying property, so where it is necessary to know the script can check for it. And where needed, I think you could also check for whether previous track finished or skipped by checking previous tracks play dates.

I think there are definite merits to the OnPlayCounter, but I don't really need that and my main concern is being unable to determine if play counter changed by sync or by player finished a track. If there would be a simple way to determine this, then perhaps it could work.