Sound Events

[Greg Sealby]

I'm not getting any sound events and was wondering if anyone else has had this issue and can help point me in the right direction.

I have a simple config for sounds as per below:

    try_again_1:
        file: TryAgain.wav
        events_when_stopped: try_again_sfx_finished
        events_when_about_to_finish: try_again_sfx_about_to_finish
        about_to_finish_time: 0.1s

In my mode config I have some logic based on these events firing at the completion of the sound (try_again_sfx_finished) or when it is just about done (try_again_sfx_about_to_finish) , but they never seem to get posted by MPF.  I am not seeing any of these events in either the MPF or MC logs.

I have managed to hack around it using a timer, but would prefer my logic to be event based.

Is there something missing from my config that I need for these events to fire?

[Cole M]

This is probably not the solution, but I remember having some trouble with using filenames with capital letters in them. Eventually I had to lowercase all my file names. If I am remembering it correctly some parts of MPF/MC were case sensitive and some parts were not. This caused different parts of the system to not respond to one another when handling the name.   

[Greg Sealby]

Thanks Cole.  I will try that and see if it makes a difference.

[Anthony van Winkle]

Hello Greg-

I recognize this because I bashed my head against it many times before I figured out that the sound events are triggered by the sound player, not the sound itself. A config like this will not work:

sound_player:

  trigger_event: try_again_sound

sounds:

  try_again_sound:

    file: try_again.wav

    events_when_stopped: try_again_sfx_finished

Instead, try a config like this:

sound_player:

  trigger_event: 

    try_again_sound:

      events_when_stopped: try_again_sfx_finished

sounds:

  try_again_sound:

    file: try_again.wav

It's the sound player event that queues up the following events to play, which it reads from its own config and not the sound's. Hope that helps!

[jabdoa]

I guess we should reject those options in sounds if they won't work. Alternatively, we could implement them. Silent failure always sucks.

Ja

[Quinn Capen]

The sound_player is just supposed to be able to override settings in the sound. Those events should work when specifying them in the sound config. Looks like a bug. I will investigate and fix.

Quinn

[Quinn Capen]

Anthony,

It appears the change you made in January (https://github.com/missionpinball/mpf/commit/ea54a63ce94287bccbe876deb507ef71dfe05d71) may have caused this behavior. The 'use_sound_setting' values were set as defaults to be able to determine if a sound setting was provided by the user in the sound_player rather than inheriting it from the underlying sound.  The effect after the change is that if a setting is not provided in the sound_player, it will default to None and override the setting specified in the sound itself.  Do you remember what issue you resolved with that change? I'm leaning towards restoring the old config_spec settings for sound_player to fix this issue unless that breaks something else.  Be happy to discuss this more in the dev slack if you'd like.

Thanks,

Quinn

[Anthony van Winkle]

Hey Quinn-

The problem I was tackling was MPF/MC interpreting the use_sound_setting value as a literal string, i.e. posting the event "use_sound_setting" instead of the event name in the sound's actual setting.

The issue filed for the bug is here: https://github.com/missionpinball/mpf-mc/issues/344

And the explanation of my changes are here: https://github.com/missionpinball/mpf/pull/1302

I'd greatly appreciate your thoughts on how to remedy what I broke as well as what I was trying to fix! Thanks!

-Anthony

[Quinn Capen]

Anthony,

Nice explanations on your PRs and issues.  I need to refresh my knowledge of config validation before solving this one.  It appears the original code I wrote did not handle sounds in shows very well with those settings (leading to those literal use_sound_setting events getting posted), but did work as intended in the sound_player.  So the challenge here is to be able to override just about any of the sound settings when using the sound_player or show (including setting them to None), but only overriding a value when it is provided explicitly in the config (don't want to override any settings with default values).  That was the idea behind setting special values as defaults in the sound_player config spec (those values are specifically checked for in the code and then deleted before merging with the original sound settings).  I will spend some time re-familiarizing myself with the applicable code and post back here before I proceed with any changes.  Any input you have would also be appreciated.

Quinn

[jabdoa]

Can you create an integration test (in mpfmc/integration/) for those cases? With that built we can easily fix the parsing issue and also prevent regressions in the future. If you build the test I can fix the parsing if you want.

Jan

[Quinn Capen]

Jan,

Simple integration test has been added (and an existing sound loop integration test fixed) and merged into dev.  It should pass, but currently fails.  I'm still looking at the code to come up with a fix, but open to any quick suggestions.

Quinn

[jabdoa]

Thanks. I will have a look.

Jan

[jabdoa]

This should fix the issue: https://github.com/missionpinball/mpf-mc/pull/378

Jan

[Greg Sealby]

Thanks Anthony.  This worked perfectly well.  Appreciate the help.

[Quinn Capen]

I have implemented this fix and a few other audio-related fixes in dev and have back-ported the changes to 0.52 which has been updated today.  You will need to update both mpf and mpf-mc.

Let me know if you run into any issues with the updates.

Thanks,

Quinn