A little introduction, I’m working on a musical app that uses FMOD as its audio backend to create compositions based on pre-configured parts. These have 3 possible ‘Themes’ and 3 possible ‘Layers’; all of these have release/fade samples for the transitions.
In order to try and make it as clean as possible, I used nested events so I could have the events end asynchronously, but when I have the Event Instrument inside a loop it does not get retriggered, only if the playhead goes somewhere else before going over that instrument. Is this a bug or they have been designed not to be retriggered in this manner?
With that said, I have tried several techniques to make these transitions and the currently working one is way too cumbersome and time consuming. I have left the link for an example project below for reference.
testEvent1 - Themes are changed horizontally, Layers are changed vertically. The problem here is that I use track volume for the changes and thus the fade-outs/releases don’t play. Tried also to have their playback dependent on a parameter and encountered problems with it too.
testEvent2 - Tried to use nested events as mentioned above, but encountered that bug of the instrument not being retriggered if it’s within a loop region.
testEvent3 - This is the implementation that I have currently working, with transitions to every single theme and layers, which makes things way too time consuming to set it all up and apply the transition files in their respective timelines.
Apart from the above, any suggestions on how to approach this would be greatly welcomed!
This is not a bug. It is the intended and expected behavior.
Instruments are triggered when the playback position enters the instrument, remain triggered as long as the playback position remains on the instrument, and become untriggered when the playback position stops overlapping the instrument.
If you want to retrigger an instrument inside a loop region, you must ensure that the playback position leaves the instrument and then returns to it within that loop region.
I have worked around that issue, and despite it not looking as clean it does work. Now I have another issue though: the nested event gets cued on parameter change, but if the same parameter changes before it gets a chance to play I need to cancel its playback. I haven’t found a way to be able to do so.
There are two ways in which you could tackle this issue.
The first and most reliable is to avoid setting the parameter to a value that will trigger the instrument if you do not intend to trigger the instrument. There are countless ways of doing this; which ones are viable depends on your game’s unique requirements. Tools such as seek speed and parameter velocity may help, depending on the context.
The second method is to enable the event instrument’s cut mode so that it stops immediately when untriggered, meaning that it will never actually play its content if untriggered before it begins to play. Of course, this will mean the event instrument will stop when untriggered in other situations, too.
Essentially the user has control on the progression of the music and everything needs to happen on the right beat and allow for the user to change his/her mind and make changes until the moment of change.
I’ve trying to hold off the change until the beat, on the engine side, but sometimes it’s already too late for the change to happen correctly on the FMOD side, and trying to ‘prepare’ the change in FMOD without quantization of the parameters also causes unwanted behaviour.
I have tried the Command Instrument option you mentioned on another post, but I still don’t have the behaviour that I want and still get multiple instruments being triggered at the same time despite the quantization.
The usual solution to requiring behavior to occur at specific arbitrary timeline positions is to use synchronous instruments. Is it possible to use them in this case?
Yes, it is definitely possible. Though, as you can see on the example project I sent to exemplify my problem, due to the fact I need a ‘release/fade’ for every transition, it gets very troublesome to set everything up.
I’m not sure if you have looked at the attached project on the original post, but I believe it might exemplify what I’m talking about in an easier way. Please feel free to send me a project with an example of your solution, in case I’m missing something.
Have you considered using quantized magnet regions rather than transition markers? The advantage of magnet regions is that you only need to create one marker for each destination, rather than one marker for each source-destination pair, which is useful if every transition would require the same transition timeline length and contents.
As I mentioned, there’s an issue with the crossover between the regions which cannot also be fixed by the magnet regions.
I refer to the project I shared in my first comment, which I shared so the replies could be relative to that, given that’s the material I need to make work.
So far the nested events were the closest to a good workflow I have found, but I cannot have them be triggered without the possibility of ‘cancelling’ them in case the user wants to do so.