play-sound action

[Canop]

Fix #303

Root level preferences let you enable/disable sound, and set a global volume:

[sound]
enabled = true # if false, jobs and other triggers won't lead to beeps
volume = "100%" # global volume multiplier

You can define sounds on jobs:

[jobs.check-all]
command = [
	"cargo", "check",
	"--all-targets",
]
need_stdout = false
allow_warnings = true
on_success = "play-sound(name=90s-game-ui-6,volume=50)"
on_failure = "play-sound(name=beep-warning,volume=100)"

You may even have a bip key (this sounds essential, right?):

[keybindings]
b = "play-sound(name=car-horn)"

Sound is feature gated. The feature is enabled by default but may be removed by compiling with --no-default-feature to gain about 1MB on the bacon binary.

[Canop]

I'm not familiar with audio in Rust so anybody's welcome to look at the beep function and provide insight regarding reliability, resource usage, platform compatibility, etc.

[c-git]

I feel like defaulting to false might be better. I don't know if everyone will want this enabled.

[Canop]

It defaults to false. This specific line in bacon's bacon.toml is only for easier tests of this PR and my intent was to remove it on merge.

[c-git]

Oh ok makes sense.

[c-git]

I really like how clean and simple your code is. Finished reviewing the code. Will test it and let you know how I find it.

[c-git]

I don't hear anything. How do I view the log?

[Canop]

Start bacon with BACON_LOG=debug bacon: this writes a bacon.log file.

[c-git]

ok thanks wasn't sure where the logs were going

[c-git]

Thank you. I found what I was doing wrong. Before I go further I want to say that as the code currently is would meet my current needs and it's unclear to me if it's worthwhile to make any changes. That said the following are things that came up while testing:

Global defaul

It would be nice to be able to set a "global" default value for all jobs. I actually thought that you could set default values for all jobs in the top level of the perfs.toml but it seems that it is a special case for on_change_strategy.

Reason

I may actually want it for all projects as my default. I don't want this right now but I'm uncertain how I will feel in the future as I used to have that as my default when I was working on my last project in python (using a custom run script before I knew about bacon). But each run was usually north of 30 seconds for the short runs so it didn't have any chance to be annoying. But just doing cargo check can be very short and I'm uncertain if I'd ever want that as the default.

Enabled via CLI

It would be nice to be able to override if beeping is enabled or disabled for all jobs with a cli flag because when I need it often depends on if I'm planning to stay at the computer to work or keep on walking away but this is also able to be solved by having more than one version of jobs so not needed. Only raising it for consideration in case it actually makes sense.

[Canop]

Added it at the root level.

A side effect is that now you can enable it via cli:

bacon --config-toml 'beep_on_end=true'

[c-git]

Oh that's great, thank you very much. I'll keep testing it but it's good as it is right now for me.

[c-git]

I've only been working for about half an hour and the beep is a bit loud for me. Not sure what we can do about that. Don't want to throw the baby out with the bath water. I'm glad to have it but it's a bit loud for me.

[c-git]

I found a work around, I timed it and set the volume on the OS level. It's only half a second long but that's long enough to adjust it if you time it just right. So I'm good and I don't really have a good proposal for how to fix it, so I'm ok with it as is.

[Canop]

I'd like to have a small set of available sounds and in the future have settings more like

beep_on_end = {
    enabled=true,
    sound="simple-beep",
    volume=0.3
 }

[c-git]

Yes that's a solution to the problem. I didn't think of nesting it. I didn't want to pollute the settings space more. That makes sense.

Another setting that would be good is sound based on job outcome, like one for success and a different one for failure.

[c-git]

I recall using a pin drop sounds long ago but don't recall where I got it or what licence it was, but it's an idea for us to explore in terms of alternates.

[Canop]

I'll change the way it's configured, so that

• it can be called on action (you can decide to have a key just to beep)
• we can disable it globally, not just job per job
• we can set up the volume
• we have (as you suggested) a different one for failure (or just bip on failure)
• it becomes trivial to handle several sounds by name

This requires some refactor of how actions are managed in bacon, but I don't like the beep_on_end we have now.

[c-git]

Hi,

Tested and this is great even just the difference in volume between success and failure is already a big help. I'm not sure if the keybind is useful for more than testing but it doesn't hurt. Only thing is we seem to have lost the ability to enable sound for all jobs without needing to edit each job. Exposing on_success and and on_failure at the top level could easily lead to loops I guess, not sure what would be a good way forward. Perhaps exposing them with a warning if they specify a job that doesn't override the on_success or on_failure?

[Canop]

Only thing is we seem to have lost the ability to enable sound for all jobs without needing to edit each job.

I might in the future add that but I'm not convinced it's a good idea.

[c-git]

Agreed, but it was nice being able to enable it across all jobs from the command line. I'll just have to edit the jobs to include it for now and toggle the global enable flag from the CLI. It's fine I guess.

[Canop]

Changed things again... now there's a collection of sounds.

Sound name can be ommited. Possible values are "2", "90s-game-ui-6", "beep-6", "beep-beep", "beep-warning", "bell-chord", "car-horn", "convenience-store-ring", "cow-bells", "pickup", "positive-beeps", "short-beep-tone", "slash", "store-scanner", "success".

[c-git]

nice, didn't get to try all yet but they are pretty cool.

[c-git]

Tried all of them and some of them aren't for me but I think the variety is good. It doesn't matter if I don't like all of them I don't have to use those I don't like. slash in particular was kinda weird. Overall I feel there is enough variety that there is something there for everyone so I think it's good.

[c-git]

Tested with the following bacon.tom and global volume seems to have no effect. I also tried volume=0.5 and volume=10

[sound]
enabled = true
volume = "1%"

[jobs.check]
command = [
  "cargo",
  "check",
]
on_success = "play-sound(name=beep-beep,volume=50)"
on_failure = "play-sound(name=beep-warning,volume=100)"

[keybindings]
b = "play-sound(name=car-horn)"

[Canop]

That's because there's an error in the doc and default prefs: it's base_volume not volume.

[sound]
enabled = false # set true to allow sound
base_volume = "10%" # global volume multiplier

[c-git]

That's because there's an error in the doc and default prefs: it's base_volume not volume.

[sound]
enabled = false # set true to allow sound
base_volume = "10%" # global volume multiplier

Thanks that does fix it.

---

On another note

In playing with this I've wondered if there is a way to have a default job settings instead of needing to manually make some global.

Like a for example the following (I note that some already have globals like env but that's what I mean instead of some)

[job-defaults]
need_stdout = true
env.TEST_LOG = "true"
on_success = "play-sound(name=90s-game-ui-6,volume=10)"
on_failure = "play-sound(name=short-beep-tone,volume=30)"

It's not a default job but has all the things that a job has and any job that doesn't have that thing inherits from that. I only see one material problem is again back to the problem of loops with the on_success and command (it doesn't really make sense for that to have a default).

Until now I haven't really wanted/needed it. I thought that the stuff defined at the global level provided a default for all jobs until I started testing this actually because it worked for on_change_strategy and I hadn't tried anything else.

[Canop]

That's an interesting approach. But it's probably not really simpler to manage and understand if you take into account that you're expected to use several prefs/conf files and that one of them would probably define only some of those properties.

[c-git]

Yeah that's true. I think I'll stay with it as is for now and see if I can find a way to reconcile an approach that would seem obvious.

PS. Part of my motivation is that I use a lot of the default jobs to keep my bacon.toml files small but I want sound in them so now I'm having to define them in perfs.toml to add sound. Not a problem but would have been nice to not need to do it per job. And all of them are copy paste.