|
|
image.png (52,926 bytes) |
|
|
The API is already there. Peke probably means that the functions to get/set the settings are undocumented, namely: app.settings.utils.getTrackTypeSettings(); app.settings.utils.setTrackTypeSettings(...); and currently needs to be sniffed from DevTools > dlg_Options > pnl_PlaybackRules Or do you mean that there should be an ability to disable crossfade per track (no matter what type the track is)? i.e. new properties like track.canCrossfade, track.fadeIn, track.fadeOut to override the type settings? |
|
|
Something in middle I meant that we expand https://www.mediamonkey.com/docs/api/classes/Player.html methods with "getPlaybackRules" which would return "pnl_PlaybackRules" for currently playing track but also like you proposed add new properties track.canCrossfade, track.fadeIn, track.fadeOut, track.canShuffle, track.canAutoDJ and track.remoceSilence to allow Addon developer to control current Player behavior more precisely. Also https://www.mediamonkey.com/docs/api/classes/Player.html#event_playbackRuleChanged would be nice so that Addon Developer can force/override some rules.. i.e. It would make scripts like http://solair.eunet.rs/~zvezdand/QueueListMM5.htm be more accurate and also allow something like "Play now new episodes from podcast and continue normal playback" or "Disable Crossfade and remove silence for this album" or "Repeat this track 5 times with crossfade" ... EDIT: any change to playback rules would be only temporary eg. for currently playing track (unless repeat one is enabled where same track would be played) and would reset if https://www.mediamonkey.com/docs/api/classes/Player.html#event_playbackState , https://www.mediamonkey.com/docs/api/classes/Player.html#event_trackSkipped is triggered. |
|
|
Assigned to Michal for a review what to implement for the script's usage.. |
|
|
Well, the mentioned Queue List add-on is using some very dirty hacks because of the lack in MM API, but I don't see how this new Playback Rules could change it for better. The add-on is using some tricks with stopAfterCurrentTrack, but that part of code is working fine. However, I mostly have problem with the current playbackState event, because of which I would like too see the whole Player class exposed and implemented in JavaScript, so that it can be analyzed and eventually overridden if needed. |
|
|
I was thinking that exposing PlaybackRule would at least for most part expose how MM player is thinking and how it will end track playback so that you can prevent more easily wrong behavior. And what about adding forceNext(param track object) method so that along with setting playbackrule you can immediately set force which is next track when playbackState (trackchange) triggers? Or if I got it correctly on playbackState (trackchange) -> you can set -> ForceNext(Track from queue) -> Set custom playbackrule -> wait next -> playbackState (trackchange)? Only problem I see is when user triggers event_trackSkipped what would your addon do eg. go to next track in Now Playing or next track in Queue. Re change for better: Disabling crossfade/gap, AutoDJ, remove silence, fade in/out would give you more freedom to control your queue addon (my 2 cents). |
|
|
Yeah, it would be nice if scripts could have a better control what will be played next, especially in Shuffle mode, but my script would still have problem with the playbackState event, which is a complete mess IMHO, mostly because of your asynchronous execution resulting with random results. You see, there is not any guarantee that you will get the correct result for e.g. player.isPlaying or player.getCurrentTrack or player.trackLengthMS or player.trackPositionMS... when it is checked in the playbackState event handler, especially with the "stop" newState. Maybe this problem could be solved if the playbackState event returns one more argument behind the newState, which would contain an object of the current track, but I think it will be better if I just open a new issue in Mantis with my comments about it. Regarding this issue and your description, I didn't use crossfade/gap, AutoDJ, remove silence, fade in/out in MM5 scripts so far, but I though that such things are already implemented. If not, that is a mistake and I am sure that scripters would have benefit of their adding to API. |
|
|
@Peke: your approach is not possible, when playing track is changed it is too late to change fadeIn and crossfade/gap values, as they affect when each track should start to play and how. Also changes in Playlist (like what track will be next) could affect change of this. I'm thinking of adding player event like "crossfadeSettingsUpdated", which will return currently playing track, following track and object with currently active crossfade settings, which will be used when changing current track to the next. And script could listen to this event and apply changes to these settings by some new function. Such settings are evaluated for current situation only and do not change anything in playback rules. I think it is exactly what you want to achieve. |
- Anonymous
