This problem has a very simple solution, but the explanation behind it is rather long.
First, the solution:
In your “basic click” event, set the ‘Click1’ sound module to Async mode. (You can set a sound module to asynchronous mode in the deck by clicking on its ‘Async’ toggle button.) Then, click and drag the right edge of the ‘Click1’ single sound module’s trigger region to make it just barely shorter than the loop region.
As for the explanation:
In synchronous sound modules, the part of the waveform that plays depends on the position of the cursor on the sound module’s trigger region. In sound modules subject to quantization, the sound module only starts producing audio when the timeline cursor reaches one of the points to which the module is quantized. These two facts together mean that when you have a synchonous sound module that’s quantized, only the parts of the waveform that appear after one of the points it’s quantized to will ever play.
In addition, synchonous sounds react to transitions (including transitions caused by loops) by restriggering. Usually, this retriggering goes unnoticed, but it does show up in rare situations such as when the synchronous sound module has an AHDSR modulator with a non-zero attack, or when (as in this case) you have a loop region that completely overlaps the trigger region.
All these things together mean that in your current project, every time the cursor inside your ‘basic click’ event loops, FMOD Studio attempts to retrigger the ‘Click1’ sound module, but waits until a point to which the sound module is quantized. Such points happen at a frequency determined by the BPM of the parent event. When the BPM of the parent event is exactly 120, the point to which it is quantized always falls at the very start of the sound module’s trigger region, meaning that the full length of the audio file plays out. However, it you set the BPM to a slightly higher or lower value, the points to which the sound module is quantized will fall at varying points along its trigger region. Whenever the point to which the sound module is quantized is part-way along the trigger region, the waveofrm will start to play from that point, and only the part of the waveform after that point will play.
The result of the above is that, as your project is currently set up, if you set the BPM to a value other than exactly 120 BPM, the sound file will often start playing from somewhere in the middle, skipping some or all of its attack (which makes it sound quiet), or even all of the ‘click,’ resulting in it only playing the click’s nearly-silent tail.
The two parts of the solution detailed above do two different things.
Setting the sound module to asynchronous mode ensures that the sound file plays from the beginning every time the sound module is triggered. This works because asynchronous mode sound modules only care whether their trigger modules are overlapped by the cursor, not which part of their trigger modules are overlapped at any given time. This means that no matter where along the trigger region’s length the quantization point occurs, the sound file will play from its very beginning.
The second part of the above solution is to make the sound module’s trigger region slightly smaller than the loop region. This is because unlike synchronous sound modules, asynchronous sound modules do not automatically retrigger every time the cursor transitions. Without constant retriggering, a sound module only ever plays its content once - which would mean your events would click once when they start, but then never click again. Making the trigger region slightly smaller than the loop region solves this; Every time the cursor exits and re-enters the loop region retriggers the sound module. As long as the BPM is such that the point to which the sound module is quantized never falls outside of its trigger region and occurs no more than once before the cursor leaves its trigger region, this ensures that the sound module will play its content at each and every point to which it is quantized.
