Please add support for Beatport integration

[CHJ85]

Feature Description

Hi there.
Could you guys please add support for Beatport, so that I can easily import my beatport library and stream flac audio from beatport via mixxx?
There's already a commandline tool for this that you guys can use as a backend base: https://github.com/unspok3n/beatportdl
I think that would really help Mixxx, especially on Linux where DJ.studio is the only way to live mix tracks with beatport.
Thank you.

[davthedev]

I think that one may be tricky. Not technically, but for legal reasons. Someone can confirm?

An educated guess about the process is that there may be some technology integration needed, including some sort of non-disclosure agreement with Beatport to secure beforehand. In addition, they would require certain features to be disabled when streamed content is played, such as the ability to record. They sell digital downloads of individual tracks, after all. Such restrictions are difficult to achieve using an open-source codebase.

[acolombier]

Sounds like yet another usecase for mixxxdj/proposals#2
Last weekend, I was listening to a podcast from a producer that was also pitching Bandcamp over Beatport due to the true support tot provides to artists.
In any case I agree this is going to be hard, if not impossible, to get each services directly into Mixxx codebase, and we should work toward providing a clear separation of concern, which can help use to to deal with the legal aspect, in isolation of the Mixxx release lifecycle

[CHJ85]

@davthedev I don't think they would. Because the way things work over at beatport is that you can only listen and download songs in flac with their highest tier subscription or if you purchase the track. That is also the only way you can integrate the songs into dj software. So they've already thought of this, hence why the big DJ apps already have beatport integrated. So from a legal standpoint, you got nothing to worry about.

@acolombier Bandcamp is already a somewhat grey area. So Idk if I'd even touch that one with a 40 foot pole as far as integrating it into DJ software.

[acolombier]

FWIW, I don't think we should integrate any providers within the software directly, for many reasons!
But this might be something for the core team to focus more on and see if we could continue the plugin/provider proposal

[CHJ85]

@acolombier I can give you a few reasons as to why you should.
For starters, Music is cloud based now. Adopting to this would make the software a lot more user friendly.
And it's not like you have to integrate them directly into the software. Use an addon system, allowing people to add their own provider.

[Swiftb0y]

And here are a bunch of reasons why we shouldn't: https://github.com/Be-ing/website/blob/4090671ad668970e9eab8596a1a097443d369027/pages/news/2020-05-22-why-mixxx-will-not-support-streaming.html

These are completely ignoring the tremendous technical challenges.

[acolombier]

Music is cloud based now

I'm not sure what this statement aim to say. Yes, you're right, nowadays, most consumers pays for subscription and don't own actual copy or right against material. This applies to game, video, software, and music of course. Now whether this is something we should embrace or fight remains a choice for each user.

And here are a bunch of reasons why we shouldn't

If I may add some more (or perhaps rephrase some in there), is my top 3 reason of why we should had this to the core of Mixxx

1. There is many providers, with many bold community. Soundcloud, Spotify, Tidal, Beatport, Qobuz,... They all have their pros and cons, but one thing that is common to all is that their users are usually quite attached to them and if Mixxx was to support one tomorrow (say Tidal), there is no doubt that a large, likely majority of the user waiting for streaming capability would be disappointed we didn't pick their service.
   -> This means Mixxx would need to aim to support all providers eventually, which is without a doubt an unsustainable burden to the dev team.
2. Many providers have different ToS and policy regarding streaming within a DJ software. And these tends to change every now and then, depending of official deals they get with the big names. There is no doubt that they wouldn't considerate us and the collateral damage of changing their API (many cases online related to changes impacting community based client integration)
   -> This means we should expect these integration to constantly stop working, either requiring an emergency fix or simply have to accept that Mixxx ships broken feature
3. Affiliating the image of Mixxx with providers that have a track record of disrespecting their community or acting in an unethical way (Hey Spotify and Beatport) is not something we should do IMHO

Use an addon system, allowing people to add their own provider.

100% agree with this idea, and even did a draft proposal + PoC on this. But it didn't get as much traction as I hoped and I moved on to other targets now. It could very much be revived tho!

[JoergAtGithub]

These ToS usually require to disable features like recording of the main mix and the use of stem separation (e.g. https://www.digitaldjtips.com/breaking-tidal-pulls-stems-from-dj-software/ ). I've no idea how we can fullfill these contractual requirements with a plugin approach, as the user could use another Mixxx version where he removed these restrictions.
To my understanding, only a complete set of binary packages build by the same publisher using the publisher specific credentials of the streaming service can fullfill these contractual requirements.

[acolombier]

These are all requirements to be put on an API, I don't think this would be hard at all. Of course, there is always the risk of the risk of somebody building their own version of Mixxx, where they disable the measures, but this is out of our remit. There are already people today building Mixxx with Spotify integration, and while this is clearly a breach of the ToS, Mixxx isn't responsible for these deeds.

Now with a plugin design, we could also shift some of these responsibilities away, while ensuring a contract around user capabilities