MusicPlayer is already highly modular. Adding a server interface listening on some TCP port is trivial at this point. Full control via an IPython shell or just the console is already possible. (In the beginning, while it didn't had any GUI, the IPython shell interface was how I used it.) There is nothing really complicated in developing some remote control.
The way MusicPlayer manages the queue, i.e. the intelligent automatic main queue is not trivial/straight-forward to emulate in MPD and it would be hacky - that is the first and main reason I didn't used MPD. Then, using MPD wouldn't really have made it simpler, only more complicated. Forking MPD itself and extending/changing it in the way I intended would maybe have been a solution but I thought it would be simpler to just code the player engine from scratch. Despite that, MPD does not support many of the current features of MusicPlayer, like the builtin loudness analyzing algorithm, etc.
MusicPlayer is already highly modular. Adding a server interface listening on some TCP port is trivial at this point. Full control via an IPython shell or just the console is already possible. (In the beginning, while it didn't had any GUI, the IPython shell interface was how I used it.) There is nothing really complicated in developing some remote control.
The way MusicPlayer manages the queue, i.e. the intelligent automatic main queue is not trivial/straight-forward to emulate in MPD and it would be hacky - that is the first and main reason I didn't used MPD. Then, using MPD wouldn't really have made it simpler, only more complicated. Forking MPD itself and extending/changing it in the way I intended would maybe have been a solution but I thought it would be simpler to just code the player engine from scratch. Despite that, MPD does not support many of the current features of MusicPlayer, like the builtin loudness analyzing algorithm, etc.