Alfred Music Volume

[godbout]

change the volume of the Music.app from Alfred. useful if you're using AirPlay devices.

 

 

GitHub: https://github.com/godbout/alfred-music-volume

Packal: http://www.packal.org/workflow/alfred-music-volume

 

enjoy 🌻️

[godbout]

ok so after using it myself i found out that i would like to know the current level of the volume. currently you can get it through a notification but you need to update the workflow to allow for empty argument. it works but i'll add this as a subtext later.

[godbout]

new version 1.1.0.

 

i've tried several ways to show the current volume. the good thing with a Script Filter is that i can show the current volume as a subtext. the (very) bad thing is that it takes some milliseconds to register the typing. happened several times that i entered for example 65 and only 6 is registered, and sometimes nothing. in terms of UX it kinda sucks. so i decided to go through a notification. maybe altogether it takes about the same time, maybe even longer, but the whole thing feels more responsive. so, to my taste, more enjoyable.

 

to get the notification with the current volume, just type `mv` (the new keyword) and enter. to choose your new Music.app volume, type `mv 65` or `mv up` or `mv down`.

[deanishe]

6 hours ago, godbout said:

the (very) bad thing is that it takes some milliseconds to register the typing.

 

Because it takes so long to get the info from Music.app? What you can do is fetch the current volume on the first run, then output it in a top-level workflow variable in your Script Filter JSON feedback. That way, Alfred passes the value back to your script via an environment variable on subsequent runs of the Script Filter, so you can skip calling Music.app when the variable is already set.

Edited May 18, 2020 by deanishe

[godbout]

good point, i didn't think of this. but i don't think it comes from this. i had the same issue with my Time workflow. i think it's just the script getting called multiple times, and the time to process the query and generate the item. but i might be wrong? see with the Time workflow below:

 

 

if you type like a maniac (like i do, i type my stuff and return immediately) then the script misses what you typed during the last few milliseconds. now i use a PHP package that i made to build my Workflows because i kept forgetting how Alfred works 😂️, so that's totally possible that i'm missing something and my package (or the way I build the Workflows) could be improved. let me know if i'm missing something. any hint would be deeply appreciated!

[Mike Fisher]

@godbout This is really great! Thanks so much!

[godbout]

hey Mike, you're welcome. glad it helps.

[cesarzea]

It don't works it you are controlling the HomePod from the Music application. 

[godbout]

2 hours ago, cesarzea said:

It don't works it you are controlling the HomePod from the Music application. 

i don't own a HomePod, no idea how that looks in Music. i have an AirPort Express though that i use daily, and the volume is changed on that output. what happens in your case? any error message in the Workflow debug?

[Robertgl]

Thanks. Very useful.

[godbout]

7 hours ago, Robertgl said:

Thanks. Very useful.

hey, glad it helps. thanks for taking the time to comment.

[chris_arceneaux]

On 5/18/2020 at 11:40 AM, godbout said:

i've tried several ways to show the current volume. the good thing with a Script Filter is that i can show the current volume as a subtext. the (very) bad thing is that it takes some milliseconds to register the typing

I encountered the same behavior with a workflow that I built and came to the same solution as you. Just found this post perusing your workflow and it made me chuckle. 😊

 

I'm curious to know if you ending up finding a better way.

[godbout]

18 hours ago, chris_arceneaux said:

I encountered the same behavior with a workflow that I built and came to the same solution as you. Just found this post perusing your workflow and it made me chuckle. 😊

 

I'm curious to know if you ending up finding a better way.

 

well to be honest i build stuff and use them but quickly forget how i did them 😅️ so no, i'm not sure i came up again with building a Workflow and had to deal with this issue. i think currently i have this one, and Alfred Time. but in Alfred Time i only use the "restart" a timer, so i never have to type a description, so i never "felt" the issue again. for the Music Volume Workflow, i actually find that i never need to know the volume so i didn't bother trying to find a better way.

 

but i'm curious and was hoping that @deanishe confirms (or the opposite) that i'm not doing anything wrong and that what happens is what is supposed to happen.

[deanishe]

3 hours ago, godbout said:

but i'm curious and was hoping that @deanishe confirms (or the opposite) that i'm not doing anything wrong and that what happens is what is supposed to happen.

 

What's the question again?

[godbout]

On 5/19/2020 at 6:26 AM, deanishe said:

 

Because it takes so long to get the info from Music.app? What you can do is fetch the current volume on the first run, then output it in a top-level workflow variable in your Script Filter JSON feedback. That way, Alfred passes the value back to your script via an environment variable on subsequent runs of the Script Filter, so you can skip calling Music.app when the variable is already set.

 

On 5/19/2020 at 1:45 PM, godbout said:

good point, i didn't think of this. but i don't think it comes from this. i had the same issue with my Time workflow. i think it's just the script getting called multiple times, and the time to process the query and generate the item. but i might be wrong? see with the Time workflow below:

 

 

😙️😙️😙️

[deanishe]

Right. The slow part is establishing a connection to Music.app/iTunes via AppleScript. There's not a whole lot you can do to speed it up because of the way workflows work.

 

You could get it to run about twice as fast by rewriting (parts of) it in AppleScript or JXA, so you only have to do tell application ... once.

[godbout]

well that might be one thing but as shown below, i'm having the issue even with a Workflow that purely grabs the user input:

 

 

so there might still be something i'm doing wrong, or some option to tweak somewhere in the Workflow?

 

regarding JXA, yeah i got a few people reporting issues with Big Sur about some Workflows. thought it was a good time to dig deeper into AppleScript but after checking out a couple of books i've decided to go to JXA instead, as i'm already more proficient in that area. any recommendation for docs? seems it's quite scarce. (JXA Cookbook on GitHub already in the favorites.)

[godbout]

btw is it just me or Big Sur menubar menus suck big time? i can't access items through AppleScript, and not even navigate through basic keyboard arrow keys. UI is good but UX seems really going backwards.

[deanishe]

3 minutes ago, godbout said:

some option to tweak somewhere in the Workflow?

 

Script Filter > Run Behaviour

[godbout]

3 minutes ago, deanishe said:

 

Script Filter > Run Behaviour

 

yeah ok, so nothing new here. i'm pretty sure i've been through that before but couldn't make things run smoother. thanks for the time @deanishe!

[deanishe]

48 minutes ago, godbout said:

but couldn't make things run smoother

 

If you can't get your script running quickly with Queue Mode = "Terminate previous script" and Queue Delay = "Immediately after each character typed", the problem is your script. Interpreters take a bit of time to load, especially if you're also importing a bunch of stuff.

 

1 hour ago, godbout said:

any recommendation for docs? seems it's quite scarce. (JXA Cookbook on GitHub already in the favorites.)

 

Not really, no. The JXA Cookbook is about the best there is, and it's pretty rubbish. The whole JXA API is a dumpster fire, imo. The guy that designed it got fired, IIRC.

[godbout]

5 hours ago, deanishe said:

If you can't get your script running quickly with Queue Mode = "Terminate previous script" and Queue Delay = "Immediately after each character typed", the problem is your script. Interpreters take a bit of time to load, especially if you're also importing a bunch of stuff.

 

checked. i already had set those settings. smart. my script then. actually i couldn't say how long is the delay after the last character. 50ms? 200ms? no idea. anyways, works for now. will investigate again at the next Workflow.

 

5 hours ago, deanishe said:

Not really, no. The JXA Cookbook is about the best there is, and it's pretty rubbish. The whole JXA API is a dumpster fire, imo. The guy that designed it got fired, IIRC.

 

yeah, a few years back. that's probably why the doc hasn't changed since 2016. a pity. and it doesn't seem to go in the right direction 😭️😭️😭️

[deanishe]

4 hours ago, godbout said:

checked. i already had set those settings. smart. my script then. actually i couldn't say how long is the delay after the last character. 50ms? 200ms? no idea. anyways, works for now. will investigate again at the next Workflow.

 

Your screenshot looks very much like it's Alfred's Run Behaviour settings that are causing the slowness. The fact that it's updating at the end of each word (when you pause slightly during typing), and not in the middle of words, strongly suggests to me that Alfred isn't running your script as fast as possible.

 

Try writing the query and a timestamp to the debugger to see if you can figure out more exactly when the script is being run.

[godbout]

12 minutes ago, deanishe said:

 

Your screenshot looks very much like it's Alfred's Run Behaviour settings that are causing the slowness. The fact that it's updating at the end of each word (when you pause slightly during typing), and not in the middle of words, strongly suggests to me that Alfred isn't running your script as fast as possible.

 

Try writing the query and a timestamp to the debugger to see if you can figure out more exactly when the script is being run.

 

but that happens because of the "Terminate previous script" option. the script doesn't have time to run and return the items to be displayed. if i switch to "Wait until previous script finishes", then you see the changes "live", with a little delay. the same delay as with the "Terminate previous script". but in the latter case i'm not calling the script 300 million times 😂️

 

or maybe i'm completely out of my mind and don't get it. which is a strong possibility.

[deanishe]

Right. So it's an "organic" delay: your script never has time to finish before you type the next letter until you pause at the end of a word.

 

That’s about what I’d expect for a script-based workflow unless you have a really fast Mac. There's significant startup time for the interpreter and parsing all your imports/scripts. Python workflows are very responsive on my new iMac, but they looked like your screen recording on my old 2008 Mac Pro.

 

Try a compiled workflow (such as this one) for comparison. They load so much faster than script-based ones.

 

FWIW, with script-based workflows, I generally use Queue Delay = Automatic.

Edited September 25, 2020 by deanishe