Show HN: Onhold – Play sounds while and after shell jobs complete(github.com)
github.com
Show HN: Onhold – Play sounds while and after shell jobs complete
https://github.com/alexdelorenzo/onhold
15 comments
Interesting idea! I found Peep[1], but seems the links are dead. Still, that led me to [2] and then [3], though none implement exactly that approach.
[1] https://www.usenix.org/legacy/publications/library/proceedin...
[2] https://sonification.de/handbook/chapters/chapter18/
[3] https://github.com/dbermbach/audiocues
[1] https://www.usenix.org/legacy/publications/library/proceedin...
[2] https://sonification.de/handbook/chapters/chapter18/
[3] https://github.com/dbermbach/audiocues
There was a wonderful project "choir.io" that did exactly this: https://news.ycombinator.com/item?id=6220740
I got early access and wired it into our software, which essentially processed streams of various events. And you could get a sense for when the pace picked up, or something unusual was happening more often than normal. Sadly the project was shut down at some point.
I got early access and wired it into our software, which essentially processed streams of various events. And you could get a sense for when the pace picked up, or something unusual was happening more often than normal. Sadly the project was shut down at some point.
In iTerm 2, I have it set up to play a sound when certain commands finish, but it hadn't occurred to me that having hold music while the job is still processing could be useful.
Yet now that I think about it, there have been times when I've briefly stepped away from my desk and missed the notification sound. This utility would solve that problem!
Yet now that I think about it, there have been times when I've briefly stepped away from my desk and missed the notification sound. This utility would solve that problem!
I use the idletime (among other factors) to decide the alarm's duration.
getidle-darwin () {
ioreg -c IOHIDSystem | awk '/HIDIdleTime/ {print
$NF/1000000000; exit}'
}I have been using a script for years also called ding. By default it emits one control-G, but if it is passed a numeric argument, it emits N dings in a row with a sleep 1 between each.
A few years back I was in a grind on a project where I would kick off regressions, then 30-90 minutes later they'd finish depending on how many slots I was getting in the server farm. I had a script that sent a message to my personal email account with a magic subject line. On my email client I had a filter that detected that subject line and attached a "play a sound" action to that filter, with the sound being an alarm clock going off. That way I could kick off a regression, take a nap, then get woken up when it finished.
A few years back I was in a grind on a project where I would kick off regressions, then 30-90 minutes later they'd finish depending on how many slots I was getting in the server farm. I had a script that sent a message to my personal email account with a magic subject line. On my email client I had a filter that detected that subject line and attached a "play a sound" action to that filter, with the sound being an alarm clock going off. That way I could kick off a regression, take a nap, then get woken up when it finished.
Here's what I did to make sound come after a command:
Used like this:
[0] - https://manpages.debian.org/jessie/sox/play.1.en.html
import os
from random import seed
from random import random
seed(a=None)
def rnd():
return 200 + (random() * (2100 - 200))
duration = 0.5
freq = rnd()
os.system('play -nq -t alsa synth {} sine {}'.format(duration, freq))
Used like this:
mycommand && python3 sound.py
[0] - https://manpages.debian.org/jessie/sox/play.1.en.html
To ring terminal bell after running process
> Ctrl+g # (^g)
Or any of:
> tput bel
> echo -n -a "\a"
> echo $'\a'
> Ctrl+g # (^g)
Or any of:
> tput bel
> echo -n -a "\a"
> echo $'\a'
On MacOS instead of tput bel I use: `say "finished"` (or something)
For non-Mac users: `say` will activate a voice saying some text
For non-Mac users: `say` will activate a voice saying some text
+1 for tput bel. I like it because it's memorable. I have it aliased on the end of my unit / integration tests. It's nice for long running processes.
I like how it plays nice with linux pipes.
I've used this on macOS before to accomplish the same thing:
`afplay ~/song.mp3 & do_something_slow; pkill afplay; tput bel`
I've used this on macOS before to accomplish the same thing:
`afplay ~/song.mp3 & do_something_slow; pkill afplay; tput bel`
I used `tput bel` after everything I want to get notified on if its running long. Extra good since it works over ssh as well.
I wish there was something like this that worked for processes running in remote ssh sessions.
It doesn't do hold music, but check out https://notify.run/. It uses browser notifications so the machine that receives the notification need not be the machine that sends it.
Shameless plug: if you want to track the progress and state of long running jobs check out:
https://progvis.com
https://progvis.com
Basically, like the bridge of Enterprise D[0] (or its main engineering[1]).
The reasoning here is to recreate the experience of "feeling" the machine. Like drivers do with their cars. Like we could do in the past with HDD sounds, and now sometimes with fan noise[2].
Last time I mentioned it publicly, someone told me they use widgets with resource usage graphs for that purpose. I've started using them too, but I noticed that I generally don't look at them. Even semi-transparent, they're mostly just a blob of color that occasionally obstructs some UI I need to interact with. But sound is a separate channel, and easier to process subconsciously.
Anyone knows of tooling relevant to implement this idea?
--
[0] - https://www.youtube.com/watch?v=XajaCX88NnU
[1] - https://www.youtube.com/watch?v=GwLsBldD9kQ
[2] - During a recent debugging session, I accidentally gained some insight about the problem by noticing the fan is making less noise than it should during certain tests.