Specify an audio file for the audible bell #11548

@electronic-dk commented on GitHub (Nov 23, 2020):

Which audio file types will the terminal be supporting in this case? Only wav?
P.S. The bruh sound looks like a perfect choice for the bell, but I'd definitely like to set john cena theme as the bell sound.

@electronic-dk commented on GitHub (Nov 23, 2020): Which audio file types will the terminal be supporting in this case? Only wav? P.S. The bruh sound looks like a perfect choice for the bell, but I'd definitely like to set john cena theme as the bell sound.

claunia commented

@zadjii-msft commented on GitHub (Nov 23, 2020):

It probably shouldn't just be .wav - hopefully XAML/WinRT have some convenient APIs we could use for loading and playing audio files that'll accept a wide gamut of file types

@zadjii-msft commented on GitHub (Nov 23, 2020): It probably shouldn't just be .wav - hopefully XAML/WinRT have some convenient APIs we could use for loading and playing audio files that'll accept a wide gamut of file types

claunia commented

@WSLUser commented on GitHub (Nov 24, 2020):

Alternatively, register Windows Terminal with the "Change system sounds" feature in Control Panel so that I can choose a sound there.

I would like this to be an option as well if possible or make the sounds available at least.

@WSLUser commented on GitHub (Nov 24, 2020): > Alternatively, register Windows Terminal with the "Change system sounds" feature in Control Panel so that I can choose a sound there. I would like this to be an option as well if possible or make the sounds available at least.

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Nov 24, 2020):

If WinRT has spatial audio APIs, I might be able to hear which monitor contains the terminal that is ringing the bell.

@KalleOlaviNiemitalo commented on GitHub (Nov 24, 2020): If WinRT has spatial audio APIs, I might be able to hear which monitor contains the terminal that is ringing the bell.

claunia commented

@j4james commented on GitHub (Nov 24, 2020):

If there's not a lot of demand for a per-profile setting, I'd also be on favour of us handling this with a custom sound event that could be configured from the control panel. That way it could (hopefully) be shared with conhost too.

There's no reason why it couldn't also be set from within the Terminal settings GUI, once that's in place. It's just that the underlying config would be stored in the registry rather than the current json file.

See also: https://docs.microsoft.com/en-us/windows/win32/uxguide/vis-sound

@j4james commented on GitHub (Nov 24, 2020): If there's not a lot of demand for a per-profile setting, I'd also be on favour of us handling this with a custom sound event that could be configured from the control panel. That way it could (hopefully) be shared with conhost too. There's no reason why it couldn't also be set from within the Terminal settings GUI, once that's in place. It's just that the underlying config would be stored in the registry rather than the current json file. See also: https://docs.microsoft.com/en-us/windows/win32/uxguide/vis-sound

claunia commented

@PhMajerus commented on GitHub (Nov 25, 2020):

If WinRT has spatial audio APIs, I might be able to hear which monitor contains the terminal that is ringing the bell.

I think this should be global in Windows instead of a Terminal feature.

I've suggested years ago, especially for multi-monitor setups, to have all apps audio be spatially located according to their position. It can be difficult since Windows typically knows which process the sound is coming from but not which window precisely, but anchoring the sound to the top level window of each process would be a great option.
Locating the sound according to the desktop coordinate would require some calibration step to know where the monitors and speakers are and how their coordinates map, so it would be better as a global Windows setting.

Note Windows Mixed Reality actually does this for UWP apps already, as it is even more important when your apps are all around you in the WinMR home 3D environment instead of in a 2D desktop.

@PhMajerus commented on GitHub (Nov 25, 2020): > If WinRT has spatial audio APIs, I might be able to hear which monitor contains the terminal that is ringing the bell. I think this should be global in Windows instead of a Terminal feature. I've suggested years ago, especially for multi-monitor setups, to have all apps audio be spatially located according to their position. It can be difficult since Windows typically knows which process the sound is coming from but not which window precisely, but anchoring the sound to the top level window of each process would be a great option. Locating the sound according to the desktop coordinate would require some calibration step to know where the monitors and speakers are and how their coordinates map, so it would be better as a global Windows setting. Note Windows Mixed Reality actually does this for UWP apps already, as it is even more important when your apps are all around you in the WinMR home 3D environment instead of in a 2D desktop.

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Dec 11, 2020):

PSReadLine 2.1.0 seems to be using Console.Beep(1221, 50) by default: Cmdlets.cs, Render.cs. Perhaps Windows Terminal could offer a configurable beep as an alternative to an audio file.

How to specify the parameters in settings,json? Could be "bellFrequency": 1221, "bellDuration": 50. IIRC, some media player supported encoding frequencies and durations in a URI, but I presume that would be more difficult to map to the settings UI, and I can't find it in IANA's list of URI schemes.
The Beep function waits until the sound ends. That could slow down Windows Terminal. Could be avoided by having Windows Terminal instead generate a waveform in memory and then play it with some other API.

@KalleOlaviNiemitalo commented on GitHub (Dec 11, 2020): PSReadLine 2.1.0 seems to be using Console.Beep(1221, 50) by default: [Cmdlets.cs](<https://github.com/PowerShell/PSReadLine/blob/3856776b1d215873a51ab0d0fe0f9a91f6ac2d67/PSReadLine/Cmdlets.cs#L121-L126> "PSReadLine/Cmdlets.cs at 3856776b1d215873a51ab0d0fe0f9a91f6ac2d67 · PowerShell/PSReadLine"), [Render.cs](<https://github.com/PowerShell/PSReadLine/blob/3856776b1d215873a51ab0d0fe0f9a91f6ac2d67/PSReadLine/Render.cs#L1240> "PSReadLine/Render.cs at 3856776b1d215873a51ab0d0fe0f9a91f6ac2d67 · PowerShell/PSReadLine"). Perhaps Windows Terminal could offer a configurable beep as an alternative to an audio file. * How to specify the parameters in settings,json? Could be `"bellFrequency": 1221, "bellDuration": 50`. IIRC, some media player supported encoding frequencies and durations in a URI, but I presume that would be more difficult to map to the settings UI, and I can't find it in [IANA's list of URI schemes](https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml). * The [Beep](<https://docs.microsoft.com/windows/win32/api/utilapiset/nf-utilapiset-beep)> "Beep function (utilapiset.h) - Win32 apps | Microsoft Docs") function waits until the sound ends. That could slow down Windows Terminal. Could be avoided by having Windows Terminal instead generate a waveform in memory and then play it with some other API.

claunia commented

@steevenlee commented on GitHub (Feb 17, 2021):

A workaround to disable it in Linux:
sudo vi /etc/inputrc
uncomment this line:
set bell-style none

@steevenlee commented on GitHub (Feb 17, 2021): A workaround to disable it in Linux: sudo vi /etc/inputrc uncomment this line: set bell-style none

claunia commented

@Don-Vito commented on GitHub (Feb 17, 2021):

Pretty noisy, need a way to disable it ASAP.

Consider using

"bellStyle": "none"

@Don-Vito commented on GitHub (Feb 17, 2021): > > > Pretty noisy, need a way to disable it ASAP. Consider using ``` "bellStyle": "none" ```

claunia commented

@steevenlee commented on GitHub (Feb 17, 2021):

Consider using
"bellStyle": "none"

not sure why it doesn't work for me. 1.5.10411.0

@steevenlee commented on GitHub (Feb 17, 2021): > Consider using > > ``` > "bellStyle": "none" > ``` not sure why it doesn't work for me. 1.5.10411.0

claunia commented

@Don-Vito commented on GitHub (Feb 17, 2021):

@steevenlee - can you please attach your settings?

@Don-Vito commented on GitHub (Feb 17, 2021): @steevenlee - can you please attach your settings?

claunia commented

@steevenlee commented on GitHub (Feb 17, 2021):

@steevenlee - can you please attach your settings?
Tried again, applying it to server profile works. Better to have a global setting IMHO.

@steevenlee commented on GitHub (Feb 17, 2021): > @steevenlee - can you please attach your settings? Tried again, applying it to server profile works. Better to have a global setting IMHO.

claunia commented

@Don-Vito commented on GitHub (Feb 17, 2021):

@steevenlee - can you please attach your settings?
Tried again, applying it to server profile works. Better to have a global setting IMHO.

You need to put it in the default profile to have it globally.

@Don-Vito commented on GitHub (Feb 17, 2021): > > > > @steevenlee - can you please attach your settings? > > Tried again, applying it to server profile works. Better to have a global setting IMHO. You need to put it in the default profile to have it globally.

claunia commented

@bbhoss commented on GitHub (Mar 7, 2021):

It would be nice if the bell were configurable per-profile. That way if you had something that emitted a bell when it was finished executing a long-running process, you could easily distinguish it from the default bell.

@bbhoss commented on GitHub (Mar 7, 2021): It would be nice if the bell were configurable per-profile. That way if you had something that emitted a bell when it was finished executing a long-running process, you could easily distinguish it from the default bell.

claunia commented

@zadjii-msft commented on GitHub (Mar 8, 2021):

@bbhoss yep, we're definitely planning on making this per-profile. In fact, the "bellSound": "bruh.wav" example from earlier was exactly what convinced the team to make the bell settings per-profile in the first place 😉

@zadjii-msft commented on GitHub (Mar 8, 2021): @bbhoss yep, we're definitely planning on making this per-profile. In fact, the `"bellSound": "bruh.wav"` example from earlier was exactly what convinced the team to make the bell settings per-profile in the first place 😉

claunia commented

@Lexicality commented on GitHub (Oct 7, 2021):

If possible, I would very much like the ability to set a bunch of bell sounds and have it pick a random one each time. I think it would make situations where you get a bunch of bell tones one after the other nicer if you had a selection.

My particular use case is picking all the Untitled Goose Game harmonica honk noises so I get a harmony when I hit ^c a bunch of times

@Lexicality commented on GitHub (Oct 7, 2021): If possible, I would very much like the ability to set a bunch of bell sounds and have it pick a random one each time. I think it would make situations where you get a bunch of bell tones one after the other nicer if you had a selection. My particular use case is picking all the Untitled Goose Game harmonica honk noises so I get a harmony when I hit ^c a bunch of times

claunia commented

@zadjii-msft commented on GitHub (Oct 7, 2021):

set a bunch of bell sounds and have it pick a random one each time ... picking all the Untitled Goose Game harmonica honk noises so I get a harmony when I hit ^c a bunch of times

Okay at first I was like "this is an okay feature request but not one we'd likely get to" but now I'm all "this is a P0 must-ship for v2" 😄

@zadjii-msft commented on GitHub (Oct 7, 2021): > set a bunch of bell sounds and have it pick a random one each time ... picking all the Untitled Goose Game harmonica honk noises so I get a harmony when I hit ^c a bunch of times Okay at first I was like "this is an okay feature request but not one we'd likely get to" but now I'm all "this is a P0 must-ship for v2" 😄

claunia commented

https://user-images.githubusercontent.com/18356694/137388536-1cc87004-0510-4f3d-92e6-e1838d5c39de.mp4

@zadjii-msft commented on GitHub (Oct 14, 2021):

(obviously, audio on)

@zadjii-msft commented on GitHub (Oct 14, 2021): https://user-images.githubusercontent.com/18356694/137388536-1cc87004-0510-4f3d-92e6-e1838d5c39de.mp4 (obviously, audio on)

claunia commented

@Lexicality commented on GitHub (Jan 6, 2022):

🎉 Thank you so much for implementing my suggestion! Do you know when the next release is likely to be?

@Lexicality commented on GitHub (Jan 6, 2022): 🎉 Thank you so much for implementing my suggestion! Do you know when the next release is likely to be?

claunia commented

@zadjii-msft commented on GitHub (Jan 6, 2022):

@Lexicality At this moment, no. We've been on a bit of a slow burn leading up to the holidays. I imagine it won't be for at least a few more weeks.

@zadjii-msft commented on GitHub (Jan 6, 2022): @Lexicality At this moment, no. We've been on a bit of a slow burn leading up to the holidays. I imagine it won't be for at least a few more weeks.

claunia commented