It isn't exactly what you have in mind, but I use `play` as well as a terminal theme color change to tell me when I'm using one or another language's keyboard layout. If you put & in front of play, you can make chords.
Here's an example:
# Define notes for major seventh chord starting on A 440
A=440
C_SHARP=554.37
E=659.25
G_SHARP=830.61
if [[ "$layout" == "Finnish" ]]; then
# Play a major seventh chord ascending
kitty +kitten themes --reload-in=all Apprentice &
play -n synth 0.2 sine $A vol -30dB &
play -n synth 0.2 sine $C_SHARP vol -30dB &
sleep 0.2
play -n synth 0.2 sine $E vol -30dB &
play -n synth 0.2 sine $G_SHARP vol -30dB &
elif [[ "$layout" == "English (US)" ]]; then
kitty +kitten themes --reload-in=all Default &
play -n synth 0.2 sine $G_SHARP vol -30dB &
play -n synth 0.2 sine $E vol -30dB &
sleep 0.2
play -n synth 0.2 sine $C_SHARP vol -30dB &
play -n synth 0.2 sine $A vol -30dB &
fi
One of my friends old office had speakers and every time Jenkins failed with a build it made a short sound. It was different for each project so everyone familiar with the sound would instantly know which project pipeline failed. He liked it and had fun choosing a sound effect fitting for his own project :)
I sometimes use sounds as opposed to print statements when debugging automations or certain UI behavior, e.g. to indicate whether a certain if-condition was triggered or not.
The advantage over normal print debugging is that you get immediate feedback, and do not need to switch to a console. This is also useful when it comes to debugging split second timings (custom window movement scripts).
HELL YES!
I actually did set my shell to spawn a background task to play the vine boom whenever I entered an invalid command.
Something like
command_not_found() {
pw-play /opt/boom.opus &
}
And it actually improved my command accuracy by a lot. And it was super fun.
I used this for my pipeline that deploys a fresly baked raspberry pi image onto an SD card. It would remind me to remove the SD card and put it in the Pi, boot it and have Ansible continue to configure it. Felt awesome.
I do this, but I put it after terminal tasks like builds or test suites like task build; say complete
thank you.
Just created an alias
alias waitfor='f() { sleep $1; say "Task $2 is probably done now"; }; f'
I play different wav files when compile fails or succeeds, so I don’t need to switch to terminal from the editor. This in addition to Anybar(1) red/green icons.
1. https://github.com/tonsky/AnyBar
95% of my work (web dev) isn't so much waiting for something to happen, where a notification of any sort would be useful. Most builds etc only take a few seconds, so I just wait.
Most of the work is thinking through a problem, then ensuring it's coded correctly. The colors and syntax highlighting and squiggly lines and Typescript warnings etc (in Jetbrains) are all helpful because they are contextual. "Hey, this function isn't written right" or "you mapped this array to an invalid return type" let me know exactly what I did wrong so I can fix it.
I don't think random beeps and dings and pewpews would have the same kind of contextual usefulness, and would probably be annoying and take me out of the zone whenever I'm focused and coding.
No, I do the opposite. I keep my speakers muted when developing. I don't want sounds. But then, I'm also one of those weirdos who prefers not to use colors as well (they hinder rather than help me), so it may just be a personality thing.
Absolutely not. Cubicle farms are noisy enough as they are. The occasional beep from an ASCII Bel character is more than enough.
I also surprise myself regularly by finding that I'm still wearing noise-cancelling headphones long, long after the Zoom or WebEx has ended. When I take the headphones off, I'm surprised again by how noisy the background is, particularly the howling of the ventilation system.
Only a little bit. I have VS Code configured to emit a small sound when a terminal command fails, or when a debugging breakpoint is hit. I also used to add `; say "tests are done"` to my test command so I could go to another screen and know when my tests finished.
I don’t, but I can imagine someone using them for events that may take a while (e.g. build ended, tests ended, deploy ended), or particularly if the event is a failure they have to respond to.
Xcode at least used to have sounds for “build failed” and “build succeeded”, and IntelliJ gives you notifications for build and test failures when the app isn’t focused.
I don't personally but then again most of my work is not asynchronous in nature.
A friend of mine has a TSR application that plays sounds to simulate as if they had a mechanical keyboard which they use with their laptop. So that's something.
I used them when running some tasks. There's a shortcut for it in my dotfiles.
No - in fact I habitually leave my speaker muted, to prevent programs like Slack from distracting (and likely irritating) my co-workers in the office.
Other than 3 hours where I modified git push to play "Push It" by Salt-N-Pepa before it got annoying, nope.
I configured my Xcode behaviors to play a sound when a build is completed or when the test fails/passes.
Many years ago I had a manager who set a sound on our monitoring system to make a noise every time we got an alert. It went off non-stop and everyone started yelling at him until he turned it off.
From my perspective, this is unnecessary overhead.