I’m having a weird issue where I put multi-instruments to play synced with the beat and for some reason some of them were not playing at the time, getting delayed and activated only in the next quantization sync.
Playing as it should:
I investigated and discovered that the issue is caused when you have a time signature placed in the middle of the song. Please check the video demonstrating:
The bug is also happening in 2.01 where the original project is being made.
This is working as intended but it does need some clarification.
When you want an instrument to play on the xth bar, you place it on the timeline where you need it.
When you want an instrument to play every x bars, you add a quantization trigger condition to it,
So currently you are placing the instrument on every four bars as you wish for it to play on the fourth bar. But the quantization is telling it to play after four bars.
For this to work in the way you intend, please remove the quantization conditions from your instruments. We will look into how to clarify this behaviour in a future update to our documentation.
@richard_simms
I might’ve not been clear. the first image is a multi-instrument placed on bar 29, it has quantization on for every four bars. The second image is another multi-instrument placed four bars later after the first one (bar 33) and it has the same kind of quantization.
You can notice that they are both marked to be async and the first image shows the multi-instrument being played when the time marker passes through it. The second multi-instrument at 33, however, doesn’t play when it’s activated (even if it’s marked to play every four bars, which seems to be the case).
You can look that the tiny white bar that shows when a multi-instrument is being played is at the very first beginning of the sample. What will happen in this case is that instrument will only start playing at bar 37.
Basically, what I’m trying to achieve is a way to tell which instruments will play accordingly with the game’s progress, synced with the main music. I’ve chosen asynced multi-instrument to be placed at the beginning of the bar because this way I could render wavs with reverb tails and not worry about the tail being cut after the next instrument plays. If I chose them to be synced, I’d need to have them extended and overlapping each other because of the tail.
I’m using quantization because if the progress parameter changes and the time bar isn’t exactly at the beginning of the bar, this would cause some desynchronization between the instrument and the main song.
Am I missing something?
@Alcibiade Here’s a video with sound, demonstrating what’s seems to be wrong:
I suspect that @Alcibiade is onto something but at a more miniscule factor. Floating point issues can cause things to appear to be “on the dot” when they are actually a tiny tiny amount off.
Select the instrument giving you trouble and open Window > Console and type this command:
As mentioned, though, setting quantization is best used when triggering instruments in four bar intervals (eg. bar 1, 5, 9) whereas if you need it triggering on a beat then remove the quantization trigger and place it on the beat needed with async enabled.
@richard_simms Hi, it seems that the console command gets a wrong output when I do this, even if I position the time signature at the beginning of the song. Check the gif:
It looks like a bug to me! I hope that’s part of the problem of the multi-instruments doesn’t playing at the beat
Well, I certainly wasn’t expecting that. It seems having more than one tempo marker will cause unexpected behaviour with setting instruments via the console.
In the meantime, try to zoom in as close as possible like Alcibiade has suggested and make sure the instruments are on the line.
I’m noticing some tiny snapping to something else when you move those instruments around. Is there anything else on the other tracks that could be doing this?
Perhaps just for this one instrument you can set it to synchronous and see if that helps?
If this isn’t working still, are you able to send this event over to us to investigate further? Copy and paste this event into a blank project and send the project over.
I tried to move every other instrument in this bar to different places so it won’t snap, but unfortunately, the result is the same.
Setting it to synchronous didn’t make any difference to the instrument activation.
I’ll DM the project to you. Thanks for helping me!
This issue was due to a floating point error. When the graphical interface is rounding up/down floating points it can sometimes cause an instrument to be off the beat just so slightly enough to cause it to not trigger as expected.
The following script helped to move all instruments with conditions back slightly enough to allow them to trigger on the beat properly.
var event = studio.window.browserCurrent(); // Select the event in the Events browser first
// Gather all instrument types
var allSingleInst = studio.project.model.SingleSound.findInstances(event);
var allMultiInst = studio.project.model.MultiSound.findInstances(event);
var allScattererInst = studio.project.model.SoundScatterer.findInstances(event);
var allInstruments = [];
// Push all instruments with trigger conditions into an array
allSingleInst.forEach(function(inst) {
if(inst.triggerConditions.length > 0) {
allInstruments.push(inst);
}
});
allMultiInst.forEach(function(inst) {
if(inst.triggerConditions.length > 0) {
allInstruments.push(inst);
}
});
allScattererInst.forEach(function(inst) {
if(inst.triggerConditions.length > 0) {
allInstruments.push(inst);
}
});
// Rounds down floating point to 2 decimal places
allInstruments.forEach(function(inst){
inst.start = Math.floor(inst.start * 100) / 100;
});
Using FMOD Studio 2.02.23, I just had similar problems:
I would like to have parameter triggered drum loops that should ‘play_to_end’. for that reason I had to take an async instrument and disable ‘cut’. I did like the proposed solution in https://qa.fmod.com/t/trigger-behavior-parameter-issue/21549
However, I had problems with the instruments not being triggered. After hours of trying everything, i luckily came across this post here.
It seems as I am facing the same issue here.
This was reported 2.5 years ago, but this was never fixed, is this correct? As a workaround, i removed my time markers within my timeline, and voila, problem solved. However, I think this bug should really be fixed, don’t you think?
It certainly should be! After checking our records, it looks like this issue was never actually added to our bug tracker. This was presumably an oversight. I’ll add it now.
Are you able to tell us exactly what positions your instruments and logic markers were at when the issue occurred, or to send us a copy of a project that exhibits the issue? I ask because floating point errors tend to occur at very specific positions, and knowing at least one configuration of content that reliably causes them can make them considerably easier to track down.
Thanks for the update. I will strip the project down to make a minimal example for you.
However, from a developers perspective (with experience in realtime systems), i am curious why you are using floating points for timeline positions in the first place. I mean, since audio is generated on digital hardware, we are always dealing with discrete timing information, so we will never ever have more precision than the sample rate you have on the output. I understand that it gets handy if you use floats for stuff in the UI, definitely, but internally dealing with floats in a somehow discrete timed system is absolutely troublesome. And if things get messed up, it is a pain in the ass to debug errors like this.
I now made a minimal example to reproduce the quantization bug, and packed it into a zip. Do you have an email address or some place where I can drop it?
If you’re registered your game project on your profile page, you should be able to upload files in your profile page’s uploads tab.
The FMOD Engine actually does use integers for timeline positions. FMOD Studio uses double-precision floating point variables for the timeline in its UI only, both for the reasons you allude to and for compatibility with other parameter types.
