Multiple "ghost channels" remain after moving playhead with setParameter (bug report)

Hi, Im developing a rhythm game on unity and we’re using Koreographer.

I have been in contact with Koreographer’s support and they’ve been helping me debugging my issue.

A little premise: we’re using a single fmod event to handle all the music in our game. Then we switch between referenced tracks inside the event using a string parameter.

The problem shows up when we switch music through that parameter: koreographer starts keeping active multiple instances of channel visors, which makes koreographer react to all of them simultaneously.

This is what Eric from Koreographer found out:

You’re tapping into the internal Channel layers where audio is actually playing (while using Koreographer) and you’re seeing is that after you set a parameter to adjust the playhead, a Channel with the expected sound starts up but the old one never stops and continues to process, including loop.

Some followup details:

  1. A “Visor” in Koreographer parlance is a system that is designed to “watch” the progress of an audio source. In this case, the “Channel Visor” is a system that tracks the position of audio playback for an FMOD Channel that has been found to be playing a sound that the user cares about.
  2. Debug logging indicates that when @Boscayolo triggers a music change within his Event via a setParameter call, in addition to a new Channel starting up which properly tracks the desired playback, the previously playing Channel does not stop: it seems to continue “playing” as the position continues to change. It is inaudible, however.
    • Hoping to get information on the audibility of these channels and whether or not they’ve been virtualized.
    • This is additive: the more the setParameter call is triggered on the Event, the more “silent” Channels end up spinning.

So after some days of research this is what we found and how we solved the issue:

Symptoms:
1 transition that sounds twice or starts twice (when a magnet region triggers a transition timeline
2 Loop region that remains silent (this happens especially when the loop region is above a nested event as if it were missing the point from which it should resume)
3 Nested that does not sound when changing phases (switching between phases of the game does not restart the audio even if the cursor moves regularly).

Solution:
I solved it by anticipating the start of each phase start in the transition region (orange square) the problem arises when combining nested events with magnet regions, loop regions and transition timelines, and especially with the need to have one instance at a time, which is necessary in the rhythm based game. In older versions of FMOD venica created a referenced track that recreated the true instance of the internal event, followed the full timeline, and behaved like a nested. Now it no longer recreates an istnace full timeline but behaves like a simulator of that event, and can lose state when it has transitions or starts over in loops. In fact, in magnets it can not reinitialize correctly, not retrigger the voice, not loop and not resist the audio even if the cursor moves. I also believe that some nested functions such as async, trigger behaviors etc. have been moved, effectively creating an event instrument and not a real nested one. So just because it’s yellow doesn’t mean it’s the same nested system as previous versions; it’s a much leaner system, but in rhythm games it can cause problems in combination with clock and sync software like Koreographer. I solved most of the problems by using command instruments and making loop regions shorter than nested ones, and nested ones as long as magnet ones.

The problem with the various instances was due to the fact that in fmod events, including the music playlist, stop was never pressed. The music started only once at the beginning of the event and then changed based on parameters. But by doing so, Koreographer was unable to take the synch of the subsequent tracks. Instances of fmod events were originally kneaded and + infinity, and later moved to max instances +1 Oldest or None. This solved the clock problem but the loops broke, as the timeline started again after the magnet ends. The problem was solved by shortening nested, loop regions and magnet as explained in the previous points.

Happy to hear that you managed to resolve the issue!

If possible, could I get you to package your project (or a stripped down version of it) with the problem event to the Uploads tab or your FMOD profile? I’d like to take a closer look and ensure that the behavior you were observing isn’t a bug.

Also, what specific versions of FMOD Studio and the FMOD API are you using?