Create JavascriptPlayerProxy

[christophehenry]

Create JavascriptPlayerProxy to expose track infos to JS controllers in a safe way

[cr7pt0gr4ph7]

Thank you for the PR! As far as I can tell, the ultimate purpose of this PR is to allow JS controller scripts to access information about the tracks loaded into each deck, so it can be displayed on more advanced DJ controllers that have integrated displays.

As it stands, this seems to only be a first draft, and missing the actual integration. Here are a few notes, based on a quick initial review:

• In the end, the goal of this PR is to extend the API offered to controller scripts. This has implications about backward compatibility in the future, as once those interfaces are released, changing them runs the risk of breaking existing controller scripts.
  • For this reason, it would be advisable to only expose strictly necessary information, like title, artist etc. The waveform data seems to be the odd one out, as there a various different formats possible. I would therefore advise on excluding the waveform data for a first approach.
  • Also, it would be best to get consensus on the desired API offered to controller scripts before homing in on a concrete implementation. Could you give an example on what usage would look like in an actual controller script?

The final API might look totally different. For example, based on the current design pattern of the Engine JS API, the following design could make sense:

engine.getString(string group, string key); // returns string

engine.getString("[Channel1]", "track_artist")
engine.getString("[Channel1]", "track_title")

(As a sidenote, it is possible to mark PRs such as this as drafts until the implementation is finished).

[ronso0]

FYI the corresponding Zulip convo is
https://mixxx.zulipchat.com/#narrow/channel/109171-development/topic/Expose.20track.20informations.20to.20controllers

[cr7pt0gr4ph7]

FYI the corresponding Zulip convo is https://mixxx.zulipchat.com/#narrow/channel/109171-development/topic/Expose.20track.20informations.20to.20controllers

Thanks, I missed that! Still getting used to how the communication is spread across the different channels.

[Swiftb0y]

The final API might look totally different. For example, based on the current design pattern of the Engine JS API, the following design could make sense:

Thanks for chirping in @cr7pt0gr4ph7. I appreciate your suggestion but IMO it has also been discussed previously and rejected (See the corresponding zulip thread). The engine design is plagued of bad legacy decisions (decisions that needed to be made back then because either the current mixxx devs didn't know any better or Qt didn't give them any better choice). This is supposed to signify a break and a potential alternative to overcome that. engine.getString just continues that bad design legacy.