I’m currently refining a music system combining horizontal, vertical and generative technics.
Since I do not really like the way transition timelines work (this is just a matter of taste, the technical aspect is perfect), I’m working with async events scattered through the timeline.
I do have an issue with this approach : async events could potentially be triggered later than I expect them to be. Here is an example :
My goal is to trigger this event (circled in red, which is a transition with percussions) only if the intensity parameter has been set prior to reaching the event.
In its actual form, the event can be triggered if the intensity parameter is changed half way through this async event (the green streak). Since the quantization is set, it is not offbeat, but it occurs too late and makes the transition super strange (compared to my original intent).
I’ve searched the forums thoroughly and also tried different combinations with FMOD Studio containers and event. But I can’t think of a way to configure an async event to be triggered only when the play head enters the event if the parameter is at the right value.
In this example, the idea would be to trigger it only on the 3rd beat, or just simply ignore it if the parameters is set after the play head has moved passed the starting point of the event.
Is there a way to do that ?
You have to dimension your instrument less than one beat (while being async and uncut, so it will play entirely), and set trigger behavior quantized to the beats. By doing that, there will be only one point where the instrument will be allowed to start.
Alternatively, though it’s less elegant, you could dimension your instrument to something really short (almost a point).
As Alcibiade says, if you want an instrument to trigger only on a certain beat, you should quantize the instrument to trigger on beats, and reduce the size of its trigger region to only cover the specific beat you want it to be triggered on. This works because a trigger region represents the region of the parameter that can trigger the instrument, so shrinking the trigger region shrinks the number of timeline values at which it can be triggered.
This is indeed a perfect solultion Alcibiade and Joseph. Thank you very much for the tip. I’m gonna test this out a bit more in depth ( I only made a quick test ), as soon as I got something that works, I’ll mark one of your answer as the solution.
It works perfectly !
Thank you very much Alcibiade and Joseph.
In fact I’m afraid the solution we gave, using quantization, wasn’t correct. Could you please check the case I describe in that post and tell me if you notice the same problem?
You are indeed, right, there is a situation I did not thought of… I’m gonna answer in your thread.
In your case, note that my other solution still stands: make your instruments as little as possible, in place of (or in top of) quantization. That’s not a very elegant solution (especially for OCD people ) but it works.
Indeed ! That said, it becomes really hard to be efficient (when duplicating containers) if the things are super tiny. Especially in really complex sequences like music.
The problem you’re refering to in your thread still exists tho.
Your solution works perfectly to ensure that the layer plays only at 124.3 (if you refer to my original screenshot), and does not trigger at 124.4.
But in the case of the container being already “programed” for playback. No matter if you exit the container or change the parameter (that should technically prevent the sound to be played since the trigger behavior says explicitely “play it only at intensity X”), the sample is triggered anyway.
In my case I could just use non-async sounds. But I started experimenting with several async layers to give a “generative” aspect to the music and still keep the continuity of the score when swapping from one intensity to another.
I could drop the idea, but I’m really happy with the results I have at the moment… i would be super sad.
As mentioned in the other thread, tempo-quantized asynchronous instrument playing even if their trigger conditions cease to be met is a bug, and will be fixed in an upcoming release of FMOD Studio.