easy to switch input or output audio

[dscox]

I just tried SwitchAudio... took 30-40 seconds to install (had to install the associate brew app). Works perfectly. Was scared it wouldn't work, so really happy about that as I use this all the time!

[Mingwei]

On 10/27/2022 at 9:13 PM, vitor said:

Alan may still update this to work on Ventura, but in the meantime there are other audio switchers you may try. They require installing extra software but don’t depend on automating System Settings.

 

 

 

 

Happy to say mine (the latter one) no longer requires installing additional software, as it now directly uses macos' coreaudio api. Latest version is tested on Ventura

[vitor]

7 hours ago, Mingwei said:

Happy to say mine (the latter one) no longer requires installing additional software, as it now directly uses macos' coreaudio api.

 

That is good, but because the binary isn’t signed users will instead get a warning that it’s from an unidentified developer.

You’ve written it in Swift, so you could instead use /usr/bin/swift to run the uncompiled scripts or use /usr/bin/swift in the language dropdown in Alfred, which takes care of that for you.

[Mingwei]

35 minutes ago, vitor said:

you could instead use /usr/bin/swift to run the uncompiled scripts or use /usr/bin/swift in the language dropdown in Alfred

Will definitely look into that, good point. Would users then have to install xcode command line tools as a pre-requisite though? Did a quick google on how /usr/bin/swift interacts with uncompiled scripts because I wasn't sure and that seems to be the case (example).

 

If that's the case I'd rather include some screenshots / link to the apple support page on getting past the unidentified developer warning. From a security standpoint the difference is minimal I think, given that in both cases the source code can be easily viewed. 

 

Other considerations: Would stuff like relative paths get messy if the compiled binary is stored in a temp directory somewhere rather than the workflow directory? And what's the lifespan of the compiled binary - could affect performance, defeating the purpose of using a compiled language. Will try and see how it goes.

[vitor]

3 minutes ago, Mingwei said:

Would users then have to install xcode command line tools as a pre-requisite though?

 

Yes, but that already happens for workflows using Python 3 and anything that requires a Homebrew package, so I wouldn’t worry about it. Plus, the way Apple has set it up is that if you call /usr/bin/swift (or /usr/bin/python3) and don’t have the CLT (Command Line Tools), it’ll show a GUI dialog letting the user know and it takes literally two clicks to do. That will only happenonce. Meaning that if a user has done it for another workflow (or any other reason), they don’t have to do it for yours.

 

5 minutes ago, Mingwei said:

If that's the case I'd rather include some screenshots / link to the apple support page on getting past the unidentified developer warning. From a security standpoint the difference is minimal I think, given that in both cases the source code can be easily viewed. 

 

On the contrary, the difference is huge in both security and usability. Users likely will already have the CLT by the time they install your workflow, but even if they don’t, doing two clicks on an Apple-provided dialog inspires more confidence (and more users will go through it) then having to manually bypass a security feature.

The code cannot be easily viewed. You’re shipping a binary, which is unreadable. You may have the code in the repo, but there’s no guarantee that the binary is compiled from that code. By having it as a script, it is truly readable and one can really confirm what the code is.

 

16 minutes ago, Mingwei said:

Would stuff like relative paths get messy if the compiled binary is stored in a temp directory somewhere rather than the workflow directory? And what's the lifespan of the compiled binary

 

Would have to run more tests to know for sure how long it’s stored, but it does seem to get cached.

[Mingwei]

1 hour ago, vitor said:

The code cannot be easily viewed. You’re shipping a binary, which is unreadable.

right... should have thought of that 🤦‍♂️. quite new to this whole developing stuff for public use thing. Will definitely work on shipping a script instead then