-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interface with macOS's media controls and now playing info in Control Center #4809
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!1 Thank you very much for picking this up.
This PR is marked as stale because it has been open 90 days with no activity. |
9670686
to
1a303bd
Compare
328b63f
to
8f5ccb8
Compare
MacOSMediaPlayerService::~MacOSMediaPlayerService() { | ||
for (DeckAttributes* attributes : qAsConst(m_deckAttributes)) { | ||
delete attributes; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation note: This approach of managing memory manually is based on
mixxx/src/broadcast/mpris/mprisplayer.cpp
Lines 76 to 80 in 50c981c
MprisPlayer::~MprisPlayer() { | |
for (DeckAttributes* attrib : qAsConst(m_deckAttributes)) { | |
delete attrib; | |
} | |
} |
DeckAttributes
doesn't seem to provide an easy way to hook itself into the QObject
graph.
Since this involves Obj-C code again, I'd step up to review this, but I have a little too much on my plate right now. Feel free to ping me sometimes so I don't forget about this and can address it when I have my time. Thank you. |
fb7b792
to
dd58d98
Compare
There are still unaddressed comments from previous reviews. Also IMO, we should really introduce an abstraction for these external player concepts first. Otherwise we end up duplicating lots of code. I think #3483 contains that but its quite big for review. It would be nice if that abstraction could be factored out first... |
Do you mean #4809 (comment)?
I agree, would be really cool to have the more general abstraction for this first. |
Yes.
Do you have interest in working on that? |
I am afraid I don't really have the time to dig into that and I'm not really familiar with the relevant design and implementation choices there.
As mentioned, I think the current solution should work fine, since we create a new dictionary per track. The mixxx/src/library/coverartcache.cpp Line 97 in 6b1844e
|
What is the sate here? Is that still working? |
Sure! My hope was that we could get the interface from #3483 merged first, but otherwise the PR should be pretty much ready (though it could of course use some battle-testing). |
} // anonymous namespace | ||
|
||
MacOSMediaPlayerService::MacOSMediaPlayerService( | ||
PlayerManagerInterface& pPlayerManager) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few design questions that might be interesting though, especially for the "interface PR": Given that this service also handles control in both directions (play/pause, seeking), the question would be if the scrobbling service interface should support that too. Currently the MacOSMediaPlayerService
simply takes a play manager and then wires itself up to that, but perhaps we'd want to take the opportunity and abstract over that too.
a30cf7a
to
915dfcf
Compare
e7502ca
to
e4029b8
Compare
- Stub out MacOSMediaPlayerService - Broadcast now playing info to MPNowPlayingInfoCenter - Wire up MacOSMediaPlayerService - Remove unused dependency - Set now playing playback state - Define __MACOS_MEDIAPLAYER__ publicly - Set asset URL and media type for now playing - Set some dummy values for playback rate and time - Set MPNowPlayingInfoPropertyIsLiveStream - Register play command in MPRemoteCommandCenter - Successfully load cover art asynchronously to macOS media player - Handle case where broadcasted track is null - Add moc include - Use new CoverArtCache API
e4029b8
to
dce0c4c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great feature! Just a small suggestion, but happy to approve and merge otherwise!
const CoverInfo& coverInfo, | ||
const QPixmap& pixmap) { | ||
Q_UNUSED(coverInfo); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const CoverInfo& coverInfo, | |
const QPixmap& pixmap) { | |
Q_UNUSED(coverInfo); | |
const CoverInfo&, | |
const QPixmap& pixmap) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per our new guideline on this, introduced a few hours ago ;)
#ifdef __MACOS_MEDIAPLAYER__ | ||
m_pMacOSMediaPlayerService = std::make_shared<MacOSMediaPlayerService>(*m_pPlayerManager); | ||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means that this feature will always be enabled for user (since I assume we will probably ship a Mixxx release with MACOS_MEDIAPLAYER=on
), however I can imagine some user not wanting this integration to be on, so would you consider adding a user setting for this? Note that I'm not a Mac user, so happy to ignore that one!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, I'm not sure where to put that though. Ideally, this should probably go into DlgPrefMetadata
as proposed in https://github.com/mixxxdj/mixxx/pull/3483/files#diff-25906de66775af0b1495dd1a528cc4256dd1de4778a23a494db27fbb4c164a76
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think it sounds sensible to unify it with #3483 !
This branch exposes Mixxx's playback state to macOS through the
Media Player
framework, making it externally controllable (e.g. via control center, media keys etc.):Some notes on the implementation:
MacOSMediaPlayerService
is written in Objective-C++. This should not be an issue, given that Clang handles ObjC++ natively pretty well, but something to be aware of (I needed to tweak the clang-format config, since it would otherwise fail when trying to format some ObjC constructs)MacOSMediaPlayerService
closely follows theScrobblingService
from expose current track metadata to external APIs #3483, to make integration with the more general abstractions from the other PR for exposing playback metadata easy (in the future).To do
MacOSMediaPlayerService
, Objective-C++, linking theMedia Player
framework)-fobjc-arc
that takes care of thisFuture Directions
slotBroadcastCurrentTrack
. This isn't that urgent though since the playback position corrects itself ~every second inslotPlayPositionChanged
and might just be nice to have a smoother slider.ScrobblingService
interface from expose current track metadata to external APIs #3483 (once ready)