MSOB7YY
commented
11 months ago Could you elaborate more on what is the ideal use cases for this? I can see it can be useful for bringing related tracks, but I have some concerns:
- what is the response of these plugins?
- if they provide the music on the service (spotify for ex), then the raw url to the music should be recieved, would that be true?
- if they don't, how is it going to know the local file path of the next track? and why it needs the path to local file in the first place?
- how are plugins going to communicate back?
- using dynamic modules (like tachiyomi)? if so then do you have a working example in flutter? i don't think it's supported/stable yet
- through network calls? hmm i don't think so
btw, current track info is already exposed to the media session, apps can intercept it and get information out of it (check Pano Scrobbler, which scrobbles playing track to lastfm)
lastly, exposing the api wouldn't be any hard, but those concerns need to be resolved first
Could you consider adding support for plugins to interact with Namida.
Plugins can then reach out to various music services with the now playing track data and look for similar tracks services such as Spotify, MixCloud, LastFM, MusicMap and the plugin to respond with a track for Namida to play next.
Simple API that covers; ) Number of tracks in the playing queue and position of playing track in the queue (to determine if playing the last track in the queue) ) On a track change, Namida calls a plugins find function and passes the full file path of the playing track and metadata album, artist, track metadata (as a JSON payload?) ) Inbound request from the plugin, receive a track to play, either filepath or artist/album/track as optional metadata and Namida to add this to the end of the now playing queue