troycurtisjr

I'm not on Monterey yet, so I can't troubleshoot what is going on. Unfortunately MacOS doesn't give us a great interface to this functionality, so everything is a little bit hacky. And since this doesn't use an official interface, it changes randomly on upgrades!
 
If anyone is able to dig in to figure out what needs to happen on Monterey, I can definitely add to the code. Otherwise, I'll give it a try once I upgrade which will probably be a bit. Maybe over Thanksgiving since my only Mac is my work laptop and I can't risk killing my environment for a few days 😉.

I've incorporated @paulw snippet to hopefully support Big Sur and previous releases. I can only test on Catalina currently, so if anyone on Big Sur would try out v0.1.3 I would really appreciate it! Let me know how it works out.
 
@paulw While it might work to make mods to that plist file to do the enable/disable, I assume it'd be roughly equivalent to modifying the similar plist file in Catalina and before. That means we'd need to kill the Notification Center process to force a re-read of the preference. However, the indicator would be out of sync, which is why I opted for the keyboard shortcut method, even though that requires more manual setup.

You are right there there is not much concurrency here. None of the I/O I'm doing (or currently expect to do) with the websocket would be expected to take very long. However, there is potentially some overlapping I/O going on here. The way the GPMDP websocket API works is that there is a near constant stream of data (presuming a track is actively playing, basically it is the "current time" message), and arbitrarily interleaved in that stream is the response or responses to calls that you might make. The overlapping I/O happening *could* be during the async send and the ongoing async receives going on. Again, I'm not claiming in this simple use case there is a huge gain. After all if I was writing this in sync code, I would just have a common read function that would read messages and discard the ones I wasn't currently interested in, waiting for the desired response before returning it. I am also planning on making use a few of the automatic messages sent over, namely the playlists. So those can be read and queued off until I care about them, and interacting with them would be the same whether they were already present when I go to look for them, or whether I needed to "await" a bit for them to come in.
 
Lastly, I'm planning on pulling down the various bits of album art into a local cache to use as the icon, and that would be nice to run "concurrently". Now I'm all set to just add those pieces in! But first, I'm getting the basics all working so I can control more of my computer using Alfred!

My first (exported) workflow:
 
Do Not Disturb, Limited - Toggle the macOS Do Not Disturb feature, optionally for a specified length of time.
 

 

 

 
I was really inspired by CalmNotifications but I always forgot to toggle it back. Plus, I really wanted the indicator to reflect the current status, which didn't happen when the "set a plist value and kill NotificationCenter" method is used.
 
Releases | Source

My first (exported) workflow:
 
Do Not Disturb, Limited - Toggle the macOS Do Not Disturb feature, optionally for a specified length of time.
 

 

 

 
I was really inspired by CalmNotifications but I always forgot to toggle it back. Plus, I really wanted the indicator to reflect the current status, which didn't happen when the "set a plist value and kill NotificationCenter" method is used.
 
Releases | Source