Stream Mix integration (youtube, spotify...)

This is a interesting request and would be a valuable addition to Mixxx.

But it raises some legal questions.

E.g. the Spotify FAQ say it is licensed "only for personal use", see http://www.spotify.com/us/help/faq/premium/public-usage/. Even if a DJ uses the paid membership (http://www.spotify.com/us/get-spotify/premium/) he probably can`t legally generate income by playing tracks to an audience trough Spotify. So we might need a disclaimer which again points to the terms of use.

Furthermore the free use of the Spotify API would limit Mixxx from generating any income trough the application itself, now or later, see paragraph 3.3 on http://developer.spotify.com/en/libspotify/terms-of-use-us/ .

Well it would depend on how would you use Mixxx. Maybe I just want to record a mix to play on my car stereo. Or just wanna practice in my room.

This could be implemented with the reuse of the clementine-player code base. They support
* Digitally Imported
* Icecast
* Jamendo
* Last.fm
* Grooveshark
* Magnatune
* Sky.fm
* SomaFM
* Spotify

+1 for this functionality

Massive +1 from me.

I'll like to support the OPs original request or perhaps add a feature suggestion of my own.

I'm a hobby python programmer and thought about perhaps offering an upload feature to SoundCloud or even better Mixcloud. I know both have APIs that could support this feature.

Hi Gabriel,

thank you for offering your help.
A SoundCloud and Mixcloud upload would be a nice addition.

Please keep sure you have a powerful development environment before starting to work.
Here are some hints:
http://www.mixxx.org/wiki/doku.php/bugfix_workflow
You should ask for help at https://lists.sourceforge.net/lists/listinfo/mixxx-devel if you get stucked.

The other issue is the businesses part of connecting to commercial services.
Since a integrated upload system is a kind of in app advertise, we have to decide what are the conditions to add it to th master build.
We have discussed this some time ago. A possible work around is a Plug-In Interface for such upload tools.
Would it be possible implement the API in QT Script (Java script)? This way each service could provide it's upload extension like we currently did with controller scripts.

Releated Forum threads:
http://www.mixxx.org/forums/viewtopic.php?f=1&t=7091&p=24220
http://www.mixxx.org/forums/viewtopic.php?f=1&t=8339&p=29050

Maybe look at Clementine. They use an external plugin to add Spotify Support to the app to make sure they are not in trouble with licensing and stuff. What about a small Mixxx plugin to integrate Spotify and similar web streaming services.

A kind of plugin solution to support Spotify an similar services would be indeed the best solution. Do you have fun and time to work on it?

If you mean me: I haven't got any programming skills in c++ but I would gladly assist in development basing on how you want to implement a plugin into mixxx.

I propose a simple library extension format to add other library types later. I think every one has his own library managed in some software and wants to use it in Mixxx. So what about a format like

LIBRARY.extension
[config]
name=LIBRARY
connection=local,api,...
type=free,non-free,...
required-data=[USERNAME,PASSWORD]

[playlist]
supported=true
connection=https://api.spotify.com/v1/users/USERNAME/playlists
encoding=json
fetch-playlist-name=JSON KEY TO GET VALUE OF
fetch-playlist-index=JSON KEY TO GET VALUE OF
...

[library]
...

[search]
...

And then you can enter the values you need for the different apis or the file structures (in case of local stored libraries)

Nice Idea. Does Clementine use such format?
I am afraid that we need a lot of special case code to adopt the different services.

No, I don't think that they use such a format. There is a "spotiy" folder with alot of c++ code in it, so I think it is an active plugin, not a passive config format.
Yeah, may be we will need special case code but I think that it is easier than coding everything directly into Mixxx. And because of licensing of spotify and probably other services we will need external plugins to install.
Syntax could be like my proposition but of course XML is only a useful format.

I will try to have a closer look at the spotify plugin of Clementine if I got some time.

Hello.

Since nobody has mentioned it, I thought just to mention that Alogriddim has developed a platform DJay Pro which seamlessly integrates with Spotify.

The catch is that it is only available for Spotify premium users.

So personally for me, there is a precedent to use and integrate spotify with third party apps. It would be great if Mixxx takes this on priority since Mixxx also supports a lot of older MIDI controllers which don't receive updates anymore.

Huge +1. I registered to this bugtracker just to say this! :)

This will be a game changer for Mixxx and yes IMHO it should take a high priority.

Any news from from this side?

Correct, Algoriddim DJ allows you to use a spotify premium integration. They don't let you record your sessions into a file.

PLEASE include this!!! I personally pay for algoriddim pro and it's ONLY because of this feature.

If MIXXX can introduce this I will completely switch over as I use linux and hate to dual boot into mac just to DJ in a modern way.

This is very unlikely to happen for several reasons:
1. Mixxx is free software that respects its users freedom. As such, it will never impose artificial restrictions on functionality like disabling recording, especially not to appease some company's demands.
2. Using Spotify's API without disabling recording (and probably broadcasting too) would clearly violate their terms of service. As soon as they found out, they would probably disable Mixxx from connecting to their service. Otherwise, Mixxx would likely become known as a free way to save songs from Spotify, even by people who have no interest in Mixxx otherwise.
3. Even if Mixxx did impose artificial restrictions, it is free software, so those restrictions could be removed quite easily. Thus it is unlikely that a company demanding artificial restrictions would agree to allow Mixxx to use their service.
4. This is speculation, but I would be somewhat surprised if Algoriddim's contract with Spotify is not exclusive. No other DJ software integrates with Spotify and I suspect Algoriddim made sure that would never happen in their contract.

For Mixxx, it does not matter that Clementine can use Spotify. Clementine is a different kind of application. It does not record, nor does it broadcast, nor is it designed for playing to an audience. Mixxx using Spotify brings up legal issues as discussed by myself above and jus in comment #1 that Clementine does not have to deal with.

I dont think using 3rd party integration plugins according to their terms
and conditions are akin to restricting user freedoms. Using the third party
app is voluntary and should not be confused further.

There is still a strong case for Mixxx integration with spotify.

On Mon, 7 May 2018, 17:35 Be, <email address hidden> wrote:

> This is very unlikely to happen for several reasons:
> 1. Mixxx is free software that respects its users freedom. As such, it
> will never impose artificial restrictions on functionality like disabling
> recording, especially not to appease some company's demands.
> 2. Using Spotify's API without disabling recording (and probably
> broadcasting too) would clearly violate their terms of service. As soon as
> they found out, they would probably disable Mixxx from connecting to their
> service. Otherwise, Mixxx would likely become known as a free way to save
> songs from Spotify, even by people who have no interest in Mixxx otherwise.
> 3. Even if Mixxx did impose artificial restrictions, it is free software,
> so those restrictions could be removed quite easily. Thus it is unlikely
> that a company demanding artificial restrictions would agree to allow Mixxx
> to use their service.
> 4. This is speculation, but I would be somewhat surprised if Algoriddim's
> contract with Spotify is not exclusive. No other DJ software integrates
> with Spotify and I suspect Algoriddim made sure that would never happen in
> their contract.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/938180
>
> Title:
> Stream Mix integration (youtube, spotify...)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> It would be very useful if Mixxx could natively buffer songs on the
> fly from a stream service like youtube or spotify and then be able to
> play them like local tracks.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/938180/+subscriptions
>

When their terms and conditions require restricting user freedoms, then yes, they are the same.

Your argument about Clementine being a different app and Spotify having
user restrictions doesn't hold water because for the user the end result is
the same.

You might be looking for some moral high ground, which is of no concern to
me.

For me Clemtine and Spotify integration, both are equally important.

On Mon, 7 May 2018, 18:16 Be, <email address hidden> wrote:

> When their terms and conditions require restricting user freedoms, then
> yes, they are the same.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/938180
>
> Title:
> Stream Mix integration (youtube, spotify...)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> It would be very useful if Mixxx could natively buffer songs on the
> fly from a stream service like youtube or spotify and then be able to
> play them like local tracks.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/938180/+subscriptions
>

If you do not care about the issues raised above and using Spotify is important to you, then you can use Algoriddim djay.

Well, I just wanted to add some thoughts about what was said earlier:

The use of a special "library plugin" format was already discussed. So why not add the important options for library plugins and let users develop and share their own plugins, like for Spotify, youtube (i think Soundcloud was also stated, even if I wouldn't use it).

These could shift the legal issues from the Mixxx core application to the actual plugin developer.

If Spotify still demands the disabling of a record, couldn't you just add a plugin option to "temporarily disable recording due to legal issues" (and probably disable the plugin when the user wants to record)?

The argument that Spotify is only for private use seems queer since this other DJ app apparently uses it. Does it violate the ToS then or do they have some kind of exclusive agreement?

The argument that people could bypass these limits is only somewhat relevant: Because users could also change the behaviour of Clementine and there are already Spotify downloaders as far as I know.

Algoriddim has a business partnership with Spotify and has negotiated their terms of use.

> couldn't you just add a plugin option to "temporarily disable recording due to legal issues"

No. There would be no difference whether the artificial restriction is directly integrated into Mixxx or Mixxx provides an API for an external plugin to activate an artificial restriction. Mixxx will never impose artificial restrictions on users.

> The argument that people could bypass these limits is only somewhat relevant: Because users could also change the behaviour of Clementine

Clementine has no recording functionality, so it's not that simple. Using Clementine to record from Spotify would require adding a whole new feature to Clementine. In Mixxx, it would be as simple as deleting a few lines of code and recompiling, which anyone could do quite easily and put those modified versions online, which would then be easy to use for recording from Spotify. Because of this, it would be unlikely that Spotify would agree to partner with Mixxx like they have with Algoriddim (if their contract with Algoriddim even allows Spotify to partner with other DJ software).

> and there are already Spotify downloaders as far as I know.

Yes, and these are clearly violating Spotify's terms of use. I doubt Spotify can shut them all down as fast as they appear.

I wouldve if it wasnt a shitty program.

On Mon, 7 May 2018, 21:25 Be, <email address hidden> wrote:

> If you do not care about the issues raised above and using Spotify is
> important to you, then you can use Algoriddim djay.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/938180
>
> Title:
> Stream Mix integration (youtube, spotify...)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> It would be very useful if Mixxx could natively buffer songs on the
> fly from a stream service like youtube or spotify and then be able to
> play them like local tracks.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/938180/+subscriptions
>

> No. There would be no difference whether the artificial restriction is directly integrated into Mixxx or Mixxx provides an API for an external plugin to activate an artificial restriction. Mixxx will never impose artificial restrictions on users.
I still consider it acceptable as long as the user can simply decide between the plugin or the restriction.

I agree with the rest of your message.

---

May we move away from focusing Spotify and see if there are other music streaming services that could be implemented?

Whether the restriction is activated by a plugin or not is irrelevant IMO. Either way requires code directly in Mixxx to artificially disable functionality.

There would be the same issues with other streaming services. If they provide APIs for third party programs to use their service, their terms of service forbid recording the stream. The concept of streaming depends on this, otherwise it would just be downloading music the old fashion way.

> I wouldve if it wasnt a shitty program.

The quality of proprietary DJ programs is none of Mixxx's concern. If you have complaints about djay, you can communicate them to Algoriddim.

Streaming integration will IMHO happen one day. I'm mainly depends on a contributor who has the skills and time to do this. Is anyone interested?

> As such, it will never impose artificial restrictions on functionality like disabling recording, especially not to appease some company's demands.

Why not? We can easily stop recording once a stream is played. If that is the "price" to pay, it is fine. I never record my sets, so it would be no limitation for me.
The argument, that you can patch this feature out, can't really be serious, because it is much more easy to install a loopback soundcard (on line in the terminal) and record Spotify, than build Mixxx with such a patch included.

> Mixxx will never impose artificial restrictions on users.

That's one opinon. It is finally the users decision to use the Spotify plug-in in line with their rules or not use it. Disabling recording helps the user not to accidentally violate their rules.

It is finally Spotify's decision to give us an API key. If the do not like us, no issue, there are alternatives. This bug is requesting a general stream integration.

> I dont think using 3rd party integration plugins according to their terms and conditions are akin to restricting user freedoms.

Not offering a streaming plug-In restricts the user freedom. If the user is already paying for a stream, he should have the freedom to use it wherever and however he likes.

> So why not add the important options for library plugins and let users develop and share their own plugins, like for Spotify, youtube (i think Soundcloud was also stated, even if I wouldn't use it).

That is the way to go. We can't integrate any commercial service into Mixxx by default for free anyway, because it would be a free advertise for them.

Putting artificial restrictions in Mixxx would make Mixxx no longer free software as it violates freedom 0, the freedom to use the program for any purpose. There is absolutely no wiggle room here as far as I am concerned. I will not be associated with software that is not free and will stop contributing to Mixxx if artificial limitations are put in the code.

> Not offering a streaming plug-In restricts the user freedom.

That is absurd. Spotify (and other companies) demand restricting user freedom. There is no freedom in caving to their demands.

> If the user is already paying for a stream, he should have the freedom to use it wherever and however he likes.

I agree. Unfortunately that violates the terms of service.

I agree with daschuer, isn't it more a restriction to say "We won't allow you to develop a plugin" than to say "I give you the opportunity to disable things in the software if you want to"?

If you add this limit, but the user decides not to use any streaming plugins, we'll reach status quo - nothing changed in mixxx, the user won't notice anything.
It only gives the user the freedom to develop and install additional plugins which have the chance to disable functionality to reach their purpose.
The user is at no time forced to give up any of the opportunities for using Mixxx, there's no forced restriction on the user, it's still up to the user to develop, install, configure and use these additional plugins.

I think the plugins should not be distributed officially, I think the sharing of them will happen in the forums and stuff like that. I still go with the idea to allow them to modify mixxx options since the user explicitly requests to disable these features in order to use the plug-ins.

> If you add this limit, but the user decides not to use any streaming plugins, we'll reach status quo - nothing changed in mixxx, the user won't notice anything.

This is not true. We will have violated users' trust by allowing Mixxx to act against them (for the benefit of a for-profit company). Once this line is crossed, the user cannot trust that Mixxx will act in their interest.

> It only gives the user the freedom to develop and install additional plugins which have the chance to disable functionality to reach their purpose.

This is not freedom. This is giving power to external influences to control how the user can use data on their own computer. It turns the computer from a tool that serves its owner to a tool that a company uses to control the supposed owner of the computer for the company's interest.

If code is committed to Mixxx to impose artificial restrictions on users, I will fork Mixx.

I think Be has a lot of assumptions and is unnecessarily trying to take the
moral high ground.

This forum is for feature requests and not to debate on philosophies.

If you won't contribute to Mixxx through your assumed prejudices and
premonitions then one cannot help you unfortunately.

Spotify plugin should be available and it is upto the user to see if he/she
wants to use it or not.

On Tue, May 8, 2018 at 7:47 PM, Be <email address hidden> wrote:

> If code is committed to Mixxx to impose artificial restrictions on
> users, I will fork Mixx.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/938180
>
> Title:
> Stream Mix integration (youtube, spotify...)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> It would be very useful if Mixxx could natively buffer songs on the
> fly from a stream service like youtube or spotify and then be able to
> play them like local tracks.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/938180/+subscriptions
>

I propose the following:

If someone finds the time to work on this, we'll accept shortcomings in the application, as long as they are only activated when the user intends to activate them AND the user has full transparency about which features are disabled for what reason.

The development of the external plugins is not up to the main mixxx development and has to be done in the community.

Mixxx should not limit any of it's opportunities to cooperate with for-profit companies, any agreements are up to the plugin developers. If the companies reject cooperating with developers instead of the true application, we should not implement these streaming services.

I can totally trace the point of be. For example, I don't like FOSS which advertises with integration for different proprietary platforms and I think Mixxx shouldn't do so.
But I still think that we should offer the user the opportunity to extend their software with plug-ins, which also have the chance to temporarily modify the behaviour of the application if the user explicitly wants them to do so.

I hope we can stay with (something like) that, and see if someone is going to implement the plugin management into the application.

I fully agree to Ron here.

> If code is committed to Mixxx to impose artificial restrictions on users, I will fork Mixx.

In general, an upstream fork is a bad idea for all parties, it doubles the work without any user benefit, so lets pull together for one great Mixxx. It is much better to fork Mixxx on the user side by adding Plug-Ins.

As a Spotify user, I have already accepted the user terms and conditions of not record the Spotify stream. So if a Mixxx version disables recording in the streaming case, it does not limit me any further. For me, a future Mixxx without any streaming features is much more an artificial restriction compared to that.

Let's all take a breath and step away from the keyboards for a while. :)

I'd like to remind everyone of the code of conduct [1], and to communicate respectfully and with empathy and compassion for others' points of view. I think we're all trying to make Mixxx the best software it can be.

[1]: https://github.com/mixxxdj/mixxx/blob/master/CODE_OF_CONDUCT.md

There is no opting out of making a moral decision here. Artificially disabling features requires code inside Mixxx that deactivates the feature. An external plugin cannot do this by itself. So either Mixxx condones this or it does not. If the Mixxx community decides that it condones violating the user's freedom to use the program for any purpose, then I can no longer trust the Mixxx community. Mixxx would no longer be free software and would therefore be worthless to me, so I would fork it.

Hypothetically there could be a plugin API for external audio sources that does not impose artificial restrictions on Mixxx's functionality, but there would be no practical, legal use case for this. If someone wanted to develop a plugin that violated the terms of service of some streaming API, then it would be up to the plugin developer to bear the potential legal consequences. If someone wants to do this as a deliberate act of civil disobedience, that is up to them. Most likely the streaming company would simply revoke the API key rather than bother with legal action (unless the developer tried to get new API keys or otherwise circumvent the ban), in which case all the effort spent developing the plugin and the plugin interface would be wasted.

Let's keep in mind that a plugin API would be a big maintenance burden. It would require interfaces both for sending audio into Mixxx and ways to interact with Mixxx's GUI. FWIW Mixxx already has an interface for receiving audio from any external sources (the auxiliary inputs).

There is also the issue that a streaming service provider may decide to or be coerced into shutting down their API or go out of business, in which case all the effort spent on developing the plugin and plugin API would be wasted.

Would it be an option, to turn the limits in the other direction?

Like, the plugin has no way to edit the behaviour of Mixxx, but it has the option to query data from the software itself.

So it could check if the stream is recorded (and maybe even get notified if a record is about to start) and stop working then.

This would not change any of the behaviour of Mixxx, no artificial restriction is about to be implemented in Mixxx and it's up to the plug-ins to stop working, if a conditon in Mixxx is changing.

This way, it's not Mixxx who bears a restriction, but the plug-in code which is kinda restricted by the software.

Is this an option for keeping the software 'free' as in be's opinion?

No, that would merely change implementation details without changing the substance of the issue. If information about whether Mixxx is recording was already made available to other programs, I might have a different opinion. But that information is not presented by Mixxx for other programs because there is no use case for it except for assisting those programs in refusing to work.

Mixxx has already global accessible control objects for it: [Recording], "status" with RECORD_OFF (0.0) RECORD_READY (1.0) RECORD_ON (2.0) and RECORD_SPLIT_CONTINUE (3.0) and [Recording], "toggle_recording".
These controls might be used from a PlugIn, to enforce the streaming user conditions. If [Recording], "status" is different from 0.0 the Plug-In may stop either the stream or the recording via [Recording], "toggle_recording"

It seems I did not make myself clear enough. If code is committed to Mixxx to impose artificial restrictions on users, I will fork Mixxx. If code is committed that pretends to work around this moral issue by changing technical implementation details, I will still fork Mixxx.

Please keep to the topic. This bug is about adding streaming support to Mixxx, which there is clearly much interest in. If anyone wants to discuss the merits of that, please do so in Zulip, not here. Thank you.

Any integration of Mixxx with Spotify would explicitly violate their API terms of use even if recording was artificially disabled. From https://beta.developer.spotify.com/terms/#iv :
"Mixing, overlapping and re-mixing. You may not, and you may not permit any device or system used in connection with the Spotify Service to, segue, mix, re-mix, or overlap any Spotify Content with any other audio content (including other Spotify Content)"

Rebroadcasting music from Spotify is also forbidden:
"Integration with Third Party Services. You will not create any product or service by integrating the Spotify Platform, Spotify Service, or Spotify Content with (i) any non-interactive internet webcasting service or (ii) streams from another service."

Related:
http://djtechtools.com/2017/09/14/spotify-axes-dj-software-streaming-virtual-dj/

We regularly use Launchpad bugs to discuss whether and how to change Mixxx. Please do not fragment this discussion by trying to move it to another medium.

The T&Cs of one particular service notwithstanding, the fact remains that Mixxx should be able to make use of streaming services that do allow this use, as well as to be able to integrate custom streams such as from other remote DJs, as requested in bug #1545288 and bug #1496739.

I feel it is condescending to call your opinion fact. The fact remains that every streaming service forbids recording the stream (even Jamendo https://devportal.jamendo.com/api_terms_of_use section 3.3). It is my firmly held opinion that complying with this condition would violate the right of every Mixxx user to use Mixxx how they wish. Therefore, I would fork Mixxx if such an artificial restriction is implemented. You can have me contributing to Mixxx or you can implement artificial restrictions, but you cannot have both.

Is anyone really interested in using streaming services besides Spotify inside Mixxx anyway? Do you care enough to do a large amount of hard work implementing and maintaining code to use the service in Mixxx? Do you care enough to work on this instead of other Mixxx features? Do you care enough to risk this hard work being made worthless at the whim of a record or streaming company like what happened to VirtualDJ? ( http://djtechtools.com/2017/09/14/spotify-axes-dj-software-streaming-virtual-dj/ ) Do you care enough to risk this hard work being made worthless by the streaming company going out of business? That is not a hypothetical concern. PulseLocker shut down without warning ( http://djtechtools.com/2017/11/10/pulselocker-folds-streaming-dj-software/ ) after Serato, RekordBox, and Virtual DJ all invested in integrating the service. Spotify, the biggest player in the industry, has been in business for 10 years but is still not making a profit.

Most other music streaming services (Apple Music, Amazon Music, TIDAL...) don't even have a public API for third party developers anyway so this discussion seems moot.

I could consider this resolved if the status of this bug is changed to Won't Fix.

> integrate custom streams such as from other remote DJs, as requested in bug #1545288 and bug #1496739.

This is a separate request that is already implemented with the auxiliary inputs. There is no need for integrating user account authentication or library browsing like there would be with streaming service integration.

Those are all good points. (But whether you fork or not is your decision alone. That's the beauty of open-source.) To the other followers of this bug: would you still be interested in this feature if Spotify support was not possible due to their terms of use? I.e. are there other services you would want to use, even if recording was not possible while using them?

Apart from Be, I think all are on the same page on this.

Spotify integration is important. Recording if not available is of no
consequence (yet).

On Fri, 11 May 2018, 16:25 Sean M. Pappalardo, <email address hidden>
wrote:

> Those are all good points. (But whether you fork or not is your decision
> alone. That's the beauty of open-source.) To the other followers of this
> bug: would you still be interested in this feature if Spotify support
> was not possible due to their terms of use? I.e. are there other
> services you would want to use, even if recording was not possible while
> using them?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/938180
>
> Title:
> Stream Mix integration (youtube, spotify...)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> It would be very useful if Mixxx could natively buffer songs on the
> fly from a stream service like youtube or spotify and then be able to
> play them like local tracks.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/938180/+subscriptions
>

I think this is very important for the future, streaming is the way most people access music and DJs will go the same way once they trust it not to drop out during a gig.

As for preventing illegal recording of a stream, that should be the streaming plugins job. I would vote for implementing as: if recording is on, the stream won't play. It should be easy and avoids Mixxx restricting features. I would argue that you cannot stop a plugin from checking if recording is enabled as that restricts the freedom of the plugin developer and the streaming service to (at least try and prevent) breaches of the terms of service (which users freely accepted when they signed up).

Just a thought Deezer might be cooperative to pull users from spotify?

You never know a service for DJs which permits recording might even pop up.

Sorry for keep the controversy going, but I stand with be in this issue.
Opening the door for concessions to private for profit companies is
dangerous.

On Fri, 11 May 2018, 17:15 Paradoxcy, <email address hidden> wrote:

> Apart from Be, I think all are on the same page on this.
>
> Spotify integration is important. Recording if not available is of no
> consequence (yet).
>
> On Fri, 11 May 2018, 16:25 Sean M. Pappalardo, <email address hidden>
> wrote:
>
> > Those are all good points. (But whether you fork or not is your decision
> > alone. That's the beauty of open-source.) To the other followers of this
> > bug: would you still be interested in this feature if Spotify support
> > was not possible due to their terms of use? I.e. are there other
> > services you would want to use, even if recording was not possible while
> > using them?
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https://bugs.launchpad.net/bugs/938180
> >
> > Title:
> > Stream Mix integration (youtube, spotify...)
> >
> > Status in Mixxx:
> > Confirmed
> >
> > Bug description:
> > It would be very useful if Mixxx could natively buffer songs on the
> > fly from a stream service like youtube or spotify and then be able to
> > play them like local tracks.
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/mixxx/+bug/938180/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/938180
>
> Title:
> Stream Mix integration (youtube, spotify...)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> It would be very useful if Mixxx could natively buffer songs on the
> fly from a stream service like youtube or spotify and then be able to
> play them like local tracks.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/938180/+subscriptions
>

Opening the door for concessions to private for profit companies is
dangerous.

It's simple you use a streaming service and abide by the T&C OR you don't use it OR you get a invitation to court. Those ere the three options.

If you want a streaming service to allow you to record you need to fight them not the software that integrates their service. You need to fight for updates to the archaic laws that surround music and give all the power to the big labels.

This is the wrong place to argue for the right to record music.

Let's have a look to Youtube.

I think it suits to be implemented like this:
https://www.mixxx.org/wiki/doku.php/downloaded_streamed_tracks_support

http://doc.qt.io/archives/qt-5.5/qtwebkitexamples-webkitqml-youtubeview-example.html

Probably there is a way to catch the audio stream using QAudioInput.
If we pair this with a last.fm view, it could be really slick, because last.fm is able to redirect to youtube, spotify, or amazon music.

I think it's a reasonable position that Mixxx should only implement this feature, even as a general plugin framework, if there exists at least one streaming service for which the implementation is not a violation of terms and conditions.

YouTube is not primarily a music platform. As such, it does not have features that would really make it useful to use with Mixxx. The metadata of YouTube videos is limited to title, description, and the user that uploaded it. There is no reliable way to get track titles, album names, artist names, or other metadata from YouTube. Plus audio quality on YouTube is highly variable and often really bad.

> This is the wrong place to argue for the right to record music.

While I do believe in the right to record music, that's not the main reason I oppose integrating streaming services into Mixxx. The primary reason is that this would require violating users' freedom to do whatever they want with the software.

Hello! Waylon_R, long time watcher, first time commenter. I am with Be on this issue. It is a moral issue at this point. The only way I can see forward, completely leaving it up to people who are not mixxx developers, is by making a plugin interface so complete, that it can hook into everything, including pulling in metadata and sound. This would be like the system Kodi uses, and how plugin developers bring in streams etc, without causing the core Kodi developers direct legal hassle. Kodi developers explicitly say that they do not support streaming from illegal sources, but because their plugin framework is so broad, its technically possible. The plugin does what it wants, and is not obliged to disable any functionality.

No core Kodi developer is known to contribute to copyright infringing plugins, as far as I know, but if one was, it would taint Kodi as a whole. So, in summary, the Mixxx team would have to make a plugin framework so broad as to include metadata I/O and sound I/O but, it would be wise not to start there. And known Mixxx developers should stay away from developing copyright infringing plugins, as they are illegal, and by them doing so, would taint the team and project.

This sounds like a lot of work, I hope it never happens, because Mixxx still has a lot of work ahead of itself in other areas, and I do not wish the efforts of a good team be diluted by tasks that will take a very long time to pay off, for a very limited amount of users.

Can I play devil's advocate and propose a thought experiment?

Let's consider sudo. It violates user freedom, because everyone should have access to ring 0, right? No! It implements a policy or contract. The policy is an agreement between the computer users and its administrator. The users have certain permissions about what they can and can't do with the system. sudo is Free software even though it implements this policy. I assume everyone agrees with this.

Another case: Let's say a bank runs on an AGPL software project, GNUKnox. If GNUKnox were truly free, it would allow its users to transfer money from any account to any other account? No. There's a policy / agreement between the bank and its users about how it will execute transfers and manage the user's money.

Where does this leave us with Mixxx and streaming services? The streaming services will allow users to access music they have a subscription for under certain conditions. There's a contract between the user and the service describing those conditions. We have the option to implement that contract to let the user participate in the contract using Mixxx. How is freedom being impinged here where it isn't being impinged in the above two cases?

A similar aspect: I don't use the recording or broadcasting feature and don't care if it is disabled temporarily or not. I wouldn't even notice. Holding back the streaming functionality effectively restricts my personal freedom.

I understand and respect the motivation behind not supporting certain business models. On the other hand I would like to keep the discussions on a technical level, striving for compromises that are acceptable for each stakeholder and without categorically excluding any options upfront.

By providing the source code we enable users to modify the code and build their own, customized version. Our license allows this. I think we can agree to never accept any code contributions that would restrict those rights.

> By providing the source code we enable users to modify the code and build their own, customized version. Our license allows this. I think we can agree to never accept any code contributions that would restrict those rights.

This seems to me to be the most critical point. In case a user uses a Mixxx for to violate his contract with the streaming company, it might throw bad light on Mixxx as a whole, which may leads to backlist Mixxx as streaming client. All our streaming efforts are on a risk, so we should make sure that the forks can be identified as forks.

Does this still match your opinion?

By the way, it is quite easy to record any stream using a loopback device.
The user has already the option to violate the contract by using this, independent from Mixxx.
Since YouTube pays for GEMA it is even legal in Germany to record YouTube videos :-)

Of course including all consequences. We need to make clear that we are not willing to change our license to disallow such modifications. Changing the license wouldn't help, the source code is out of our control after publishing it.

If a shared application token is required that can be revoked at any time and will, I personally would not invest a minute into such a project. It is also an open question how to distribute such a secret(?) token. I'm afraid most services are ruled out just by Mixxx being open-source, i.e. whenever some kind of security by obscurity or validation/signature of the actual code that is running is required.

Why discuss about possible consequences and restrictions that might never become reality? Let's focus on the facts and adhere to the rules, both ours and theirs, as RJ vividly explained. Constructive input and ideas are always welcome, no taboos on thinking!

A generic streaming source integration would still be useful, though not for Spotify:

https://djworx.com/spotify-withdraws-from-dj-streaming-apparently-not-the-end-of-the-world/

I suggest to add Qobuz.
It would be really great to be able to play HiRes music via timecode vinyl records.

Does Qobuz allow DJing, regarding their terms and conditions? Do they support third party streaming clients? Do they have interest to colboration?

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/6277