Bear with me on this as I'll try to explain my situation as clearly as I can —
My game has background music associated with different sections of the "world." As the narrative structure of the game isn't linear, it's possible for the player to approach different areas in different orders; to compensate this I have a macro that fades out the currently-playing audio
<<audio ":playing" fadeoverto 2 0>>
and then the background track associated with the zone comes in on top
<<audio "CharacterCreation_A" loop play>>
This works fine except that I also have audio effects associated with clicking buttons and other UI elements, and I belatedly realised that they are also impacted by the :playing catchall — because duh, of course they would be.
My question is — is there a better way that I can do this in order to fade out the background music but not disrupt the UI audio effects? The only way I can think at the moment would be to hard code all of them like
<<audio "CharacterCreation_A" fadeoverto 2 0>>
<<audio "Zone_A" fadeoverto 2 0>>
<<audio "Zone_B" fadeoverto 2 0>>
<<audio "Zone_C" fadeoverto 2 0>>
etc etc so that it covers any tracks that might happen to be playing at the moment, but that's tedious and I'm hoping there's a smarter way to manage it. Maybe with the playlists? Can, for example, I put all of the audio in a playlist and trigger a fadeoverto macro on that
playlist even if the audio track is playing separately to the playlist itself?
Let me know if this makes no sense.
Comments
note: The above has not been tested, and it assumes you can use a story variable as a parameter to the <<audio>> macro so it may not work.
Unfortunately in my case even if you can use a variable, it won't exactly work for me — I have two tracks which play simultaneously to compensate for the fact that audio doesn't loop seamlessly in Twine/SugarCube (it has a tendency to skip for a split second on the loop, so the two tracks fade in and out and mask where the loop actually happens). So while the player only "hears" what appears to be a single audio track, there are actually two.
I could do
to compensate but it's still an inelegant solution to the problem.
The only way to achieve what you want, currently, is to hard code each of the tracks you want to affect.
That said. It shouldn't be too difficult to create a new macro which would allow the creation of custom audio groups. For example:
Still, that might also be unwieldy in certain cases, so it might be nice to have the ability to negate a group as well. For example:
Thoughts?
note: Again the above has not been tested.
This would actually probably be exactly what I want; allowing me to exempt the UI audio from any attempts to fadeout the background music. There's fewer UI tracks so it's easier to remove them from the "playing" issue entirely and have their presence ignored.
Would I put the above code in the javascript part of Twine, or call it in the StoryInit passage?
And to be sure
will function effectively the same way as
except that instead of hitting all playing audio it fades every track except those in the UI group?
Thanks for the quick work & super helpfulness as always.
If you've scattered your <<cacheaudio>> invocations around for whatever reason, then at least the tracks you intend to put into the group must have been already cached.
Not quite. I'm still mulling over the syntax, however, my current idea is that the negation must be applied to a group. In the absence of an explicit group, :all would be the default/implicit group.
For instance, your first example is equivalent to the following:
Acting only upon playing tracks not in the :ui group would look like:
That's looking vaguely CSS pseudo-class-ish to me. Not sure if that's good, bad, or just a thing. Regardless, I think I want to allow the negation to affect multiple IDs, so I may also have to allow multiple IDs to be specified period. For example:
As is currently the case, none of those will affect playlist copies of tracks—though references would continue to be fair game.
The basic functionality has been completed, I just need to polish it up a bit. I would also like to address some other QoL issues before publishing a new release, so that's an additional holdup.