Multi Instrument Inside Multi Instrument

[g.hadji]

Hi.

I’m making interactive music for an exploration based part of my game. I have a bunch of little musical motifs that I am triggering each time the player perform a set of actions, through a dedicated event. At first I’ve been using a multi-instrument, which was choosing a motif in shuffle mode each time the event was played. But because of the randomness, there was no really the feeling of hearing a constructed song. So I tried in Global.Seq mode. Here I got a really strong sense of progression, but the problem is that the structure loops and it is getting a little bit boring in the long run. So my idea was to organize my different audio asset in multis representing each part of the song. I wanted to store all those multi in another multi. The “nested” multis would be in Global.Seq mode and the main one would be in shuffle mode, so that I could get a bit of randomness in the structure of the song without loosing the progression of each parts.

Unfortunately, from what I saw, there is no such feature in Fmod. when the event is triggered, it is triggering another nested mutli each time. What I’m looking for is for the main multi to wait until a nested multi has finished playing its global sequence before going to another nested multi. Did I miss this feature ? I know there are many other ways to obtain the behavior I described above, and I am already working on it, but I was thinking that it would be really convinient to be able to use some sort of “nested multis’s sequence” in a future version of Fmod.

Thanks for reading.

[Alcibiade]

So in short, the only thing that doesn’t work is that you don’t want to trigger the next nested multi (or anything else) while the event is already playing, right? If so, you should test “is playing” on the event instance in the game code to decide whether or not the event should be retriggered.

[g.hadji]

@Alcibiade

the only thing that doesn’t work is that you don’t want to trigger the next nested multi (or anything else) while the event is already playing, right?

Sorry I may have not been very clear with my explanation. In fact I don’t want to trigger another nested multi WHEN the event is re-triggered UNTIL the current multi’s sequence is finished. Here is what it looks like :

And here is a little scheme of what I’m looking for :

Right now, the event is not triggered by the game’s code but by command instruments placed on several other events in the fmod editor. The event is set to 1 instance max with no stealing so that the next audio files is not triggered before the previous one reach its end.

[Alcibiade]

I think I’ve managed to do what you’re looking for, when I tried a bit earlier. I’ll share that to you later when I come back to my pc.

[Alcibiade]

So, the setup I came across is this:

Note the “play count”, matching the number of entries, in the nested multis.

[g.hadji]

Thanks for your response !

Unfortunately, this doesn’t solve my issue.

In this exemple, the nested multi plays the next file automatically (assuming the instance stays always the same). I need the multi to wait for the next event call to trigger the next file of the playlist.

[Alcibiade]

Ok, so nested multis isn’t the right way to do that. You should rather put everything in the timeline, use sustain points to wait for the player, and make the randomization with transitions.

[joseph]

If I understand correctly:

• The event should play one sound file each time it is triggered.
• The event should have multiple playlists of sound files it can play.
• When the event is first played, it should select one playlist at random; thereafter, each time it is triggered it should play the next sound file in that same playlist until the playlist is exhausted. If the event is triggered again once the playlist is exhausted, it should randomly select a new playlist.

There are ways of achieving this behavior, but Alcibiade says, nested multi instruments are not one of them.

One way to get the behavior you want would be to create one “Sequential - Global Scope” multi instrument for each playlist of files you want to iterate through, and lay them out along a parameter. You’ll then have to use your game’s code to keep track of which playlist you’re playing through, and to change the playlist by changing the parameter value each time a playlist is exhausted.

Another way would be to create a separate event for each playlist, create each playlist as a sequential - global scope multi instrument, and to use your game’s code to select which event to play. As with the above method, this will require you to track which playlist you are playing and when it is time to change playlists in your game’s code.

@Alcibiade

You should rather put everything in the timeline, use sustain points to wait for the player, and make the randomization with transitions.

I’m not sure I understand how this solution would work across multiple instances of the event.

As for why nested multi instruments can’t be used for this task… The explanation for that is complex and has multiple parts, so I’ll break them down into dot points.

• Instruments, like events, can be instanced. In fact, every time you trigger an instrument, a new instance of that instrument is spawned and begins to play. This is why it’s possible to trigger an instrument repeatedly by using a loop region, such that multiple instances of the instrument can be heard at the same time. Similarly, when a multi instrument selects one of the instruments in its playlist to play, it spawns an instance of that instrument.
• Whenever a new instance of a sequential multi instrument is spawned, the number of times the instrument has been instanced in the relevant scope is incremented by one. The new instance then counts through a number of playlist entries equal to that number, and plays the entry it lands on. If the number of times it has been instanced is greater than the number of entries in in its playlist, it will loop around and start from the top of the list.
• Sequential multi instruments do not treat reaching the ends of their playlists as a special or unusual event; they simply iterate back to the start of the list and keep on selecting files.
• Multi instrument instances don’t “know” the playlist state of the child instrument instances they spawn. In fact, they don’t even know what type of instruments their children are. The only things a multi instrument instance does know about its currently-playing child instrument instance is “what number playlist entry it is” and “whether it’s finished playing yet.”
• Different instances of the same multi instrument only communicate a limited amount of information with each other - specifically, how many times the multi instrument has already been instanced (either globally, in the event instance, or in the playback of the event instance, depending on the instrument’s playlist selection mode).

We could potentially change these details in order to make the kind of behavior you describe possible, but it would require some deep redesigns of how multi instruments work, and so would take a considerable amount of time to design and implement. Would you like me to add your suggestion to our feature/improvement tracker?

[g.hadji]

Hi, and thanks to both of you for taking the time to reply to my issue.

@joseph

If I understand correctly:

• The event should play one sound file each time it is triggered.
• The event should have multiple playlists of sound files it can play.
• When the event is first played, it should select one playlist at random; thereafter, each time it is triggered it should play the next sound file in that same playlist until the playlist is exhausted. If the event is triggered again once the playlist is exhausted, it should randomly select a new playlist.

Yes it describes the desired behavior perfectly, and it is way better explained than my previous messages were

I’ve managed to get the behavior that I was looking for by letting go of the nested multi instrument solution, as Alcibiade suggested, and without using any line of code, which in my case feels more convinient.

Because the setup is hard to explain in details without visual, here is a demo project of what I managed to do : sequencial playlists in random structure - Google Drive .

I use 3 global parameter :

• currentPlaylist
• lastPlaylist
• retrig

At the start of the event I have two sets of 5 transitions, leading to one of the five global sequential playlists. I also have 5 nested instruments which are triggered at the end of their related playlist inside the multis. Those nested instruments are restarting the parent event by setting the retrig parameter to 1, thus triggering the condition for the “To Start” transition region to occur (the retrig parameter is reset to 0 at each call); and are setting the lastPlaylist parameter to the value representing their multi inside the parent event. This allows us to obtain a shuffle behaviour where the last playing playlist is never repeated before the next one is exhausted.

At the begining of each playlist (in the timeline) there is a command instrument that sets the currentPlaylist parameter to the value representing the multi currently playing, so at the next call, the first set of transition can directly play the same playlist as long as the lastPlaylist parameter is different of the currentPlaylist parameter.

There is a lot of trigger conditions going on in the transitions, but basically, that’s it. It is messy but it does the trick.

Thank you Alcibiade and Joseph for your help !

@joseph

Would you like me to add your suggestion to our feature/improvement tracker?

I think the solution I came across is a little bit far-fetched, and I’d have liked to be able to use a more minimalistic option. However, I don’t think I’ve seen anybody else requesting such a feature so I leave you judge of wether or not it is relevant to add it to the tracker.

Considering the complexity of redesigning the multi instrument, and the fact that it is already a very powerful and flexible tool, I understand that it would not be a priority.