GMC looping music - anyone get this to work?

[james cardona]

I have been chasing this for about 3 days and have tried everything and can't get looping music to work on either linux or windows.

Whenever I call a music file with a loop: -1 it will not loop.

Why am I so dense-headed? This has to be something obvious.

I have tried changing the music bus from solo to simultaneous and tried several different sound_player parameters. According to the GMC logs, the parameters are passing in, it is just not looping for me.

I am not using declared MPFsound_assets, but just calling the sound files from the sound_player and passing in the parameters. Like I said, they play, they just won't loop.

Here is my sound player config:

    base_mode_baseMusic_PlayMusic3:
        main_ Music3 :
          action: play
          loops: -1
          bus: music

And after the event is thrown, here are the logs in GMC that show that the parameters make it into GMC:

18:01:45.584 : INFO : Bus<music> : Playing sound 'res://sounds/music/main_ Music3.wav'

18:01:45.584 : DEBUG : Bus<music> :  - with sound settings { "action": "play", "loops": -1, "bus": "music", "priority": 103, "fade_in": 0.1, "volume": 0.4, "block": false, "delay": <null>, "ducking": {  }, "pan": <null>, "start_at": <null>, "fade_out": <null>, "about_to_finish_time": -1, "max_queue_time": -1, "events_when_played": [], "events_when_stopped": [], "events_when_looping": [], "events_when_about_to_finish": [], "key": "main_ Music3", "file": "res://sounds/music/main_ Music3.wav", "context": "_global" }

18:01:45.584 : DEBUG : Bus<music> : Channel <GMCChannel:music_2:current_stream=None> has no stream, making it the available channel

18:01:45.585 : DEBUG : Bus<music> : playing res://sounds/music/main_ Music3.wav (<AudioStreamWAV#-9223371945922263527>) on <GMCChannel:music_2:current_stream=<AudioStreamWAV#-9223371945922263527>> with settings { "action": "play", "loops": -1, "bus": "music", "priority": 103, "fade_in": 0.1, "volume": 0.4, "block": false, "delay": <null>, "ducking": {  }, "pan": <null>, "start_at": <null>, "fade_out": <null>, "about_to_finish_time": -1, "max_queue_time": -1, "events_when_played": [], "events_when_stopped": [], "events_when_looping": [], "events_when_about_to_finish": [], "key": "main_ Music3", "file": "res://sounds/music/main_ Music3.wav", "context": "_global" }

18:01:45.630 : DEBUG : Bus<music> : Fade in to 0.00 complete on channel
<GMCChannel:music_2:current_stream=<AudioStreamWAV#-9223371945922263527>>.

Maybe there is another parameter I am missing that I need to set?

[Needlebat]

I have a testing machine set up according to Anthony's videos (https://www.youtube.com/@paradigm-tilt/videos). If I change attract.yaml to just add loops: -1 then the music loops.:

sound_player:
  mode_attract_started:
    intro_music:
      bus: music
      loops: -1

This may help you track down your problem.

[Anthony van Winkle]

Looping had some issues that were fixed in 0.1.1 back in November, so if your GMC code is older than that an upgrade may be necessary. (Note that upgrading to 0.1.3 includes a lot of bug fixes but does unfortunately require some scenes to be updated, see https://groups.google.com/g/mpf-users/c/eogaMj_sVNk for details).

[james cardona]

okay sounds like this is an isolated problem on my install. 

I upgraded GMC to the latest and the problem still exists. For those following, the version number for GMC is in the plugin.cfg file.

So please, friends, review this to see if I am doing the install correctly:

I am running two systems, the development laptop and the proposed production computer.

Both are exhibiting the same problem of not recognizing a -1 input to GMC

Development is with windows 11, python 3.11

Production is Lubuntu 19, python 3.8 (only using this because 20, 22, 24 audio drivers are not working with my old intel NUC)
I installed it initially on the Windows box and when we went to production, I just copied all the mpf directories into the environment folder of the production machine. That's probably why this perpetuates to both.

When I upgraded GMC, I just deleted the addons folder then copied the new addons folder and the problem didn't go away.

Am I missing any files or scripts using this copy method? Since the logs show the dictionary being passed from MPF to GMC I feel this is not an MPF issue but a GMC issue so I must be missing something, right?

[james cardona]

okay I figured it out.

I am using wav files for audio and that is what is breaking the looping code. When I switched over to mp3 files, looping works.

Could there be something here in this GMC channel code below that is awry?

My guess is that elif self.stream is AudioStreamWAV: is returning false for some reason and then when connect loop is called it doesn't loop since the number is negative. I am using 44.1khz wav files so maybe that is it? Is it expecting 48khz?

Anyway, I will just encode everything to mp3 for now and that will fix "my" problem, but I am still guessing there is a bug in the GMC code for wav files. Let me know if you want me to troubleshoot more to nail this down more exactly.

if settings.get("loops"):
if settings["loops"] == -1:
# For infinite looping of OGG/WAV/MPF, use the native loop
# OGG and MPF use the 'loop' property, while WAV uses 'loop_mode'
if self.stream is AudioStreamOggVorbis or self.stream is AudioStreamMP3:
self.stream.loop = true
elif self.stream is AudioStreamWAV:
self.stream.loop_mode = 1
else:
self._connect_loop(settings["loops"])
else:
self._connect_loop(settings["loops"])

[Anthony van Winkle]

Thanks James, I've looked into it and the loops: -1 is setting the wav files to loop but the loop is dependent on the import metadata for the file (which is where one would typically set the loop type, start, and end values for WAV assets). The default loop end is zero, so setting the file to loop was looping zero samples and giving you nothing.

I've updated the GMC code so that if a wav has loops: -1 but no loop_end value set, it will calculate the end based on the file's sample rate and duration. I tested with a few wav files and it seems to work.

For the case of music, you could save yourself some config lines and re-import your wavs with looping metadata—then you won't have to specify it in your configs. Select a wav file in the FileSystem panel and then open the Import panel. Change the Loop Mode to Forward and hit the yellow Reimport button to update the godot metadata for the file. The code I've written for GMC is just a programmatic way of doing the same thing, so it's okay if you want to keep your looping in the configs (namely if you don't always want to loop) but you have the option to do it in the metadata.

Thanks for digging deeper and uncovering this bug!