I’m not sure what I’m doing wrong but I’m trying to execute a very simple task within FMOD Studio and I am not getting the results I’m expecting. I’m hoping that I’m just tired and there’s something blatantly obvious that I’m missing that’s right under my nose. Let me explain what I’m trying to accomplish:
In the game, when the player gets close to an enemy, they start shooting (Shooting = true). The player will then fire the same shots one after the other in a timed fashion. The timing is already baked into the wave file assets, so no worries there. I would like each and every shot to have some random pitch and volume modulation applied as the event loops.
The problem I’m coming across is that it seems a Multi Sound only initially applies random pitch and volume modulation to the nested items in the Multi Sound. Then after each item is initially played, FMOD randomely switches between the different Multi Sound items while maintaining the same pitch and volume modulation that it determined at the start of the Multi Sound trigger. You can hear this in the following video I made below:
I want the Multi Sound to trigger, stay triggered, and have each item it randomely loops through to have a new volume and pitch variation each time it switches to a new item.
In this 2nd video I used Event Sounds nested in the Multi Sound instead of just the audio files themselves, then added random volume and pitch modulation to each single-sound module of each Event Sound in the Multi Sound Trigger, which created the volume and pitch diversity I wanted, but then something else strange began happening where there’d be these little “hiccups” in the playback. You can hear this here: https://www.youtube.com/watch?v=YH4AFsqQ0D0
Can anyone of you please tell me what I’m doing wrong? This seems pretty resource-wasteful to create separate volume and pitch modulations for each item in a Multi Sound Module. It doesn’t make sense to me that the Volume and Pitch modulation in the Multi Sound Module are only set once when the Multi Sound is triggered. There has to be a better way of doing this, so that I only have to make 1 volume modulation and 1 pitch modulation that affects all items in the Multi Sound every time a new item is looped. What obvious thing am I missing here?
This seems like an incredibly easy thing for FMOD to accomplish, yet the documentation leads me to believe it should be working the way it is set up. >_<
Heh, you got in first, so it’s really me who should apologise to you.
That won’t entirely solve the problem, I’m afraid. Even if the position of spawned sounds is not randomised, the internal 3D Panner still applies distance attenuation with a max distance of 100. This means that distance attenuation will be applied to the scatterer sound modules’ output even if the event itself is not subject to distance attenuation - and worse, it stacks with any distance attenuation applied by other parameters or effects. If your game relies on positioning the event that contains the scatterer sound module at any location other than at the exact same point as the listener, its audibility will vary. This really restricts how the scatterer sound module can be used. It can still be used for non-diagetic music, of course, or for position-agnostic ambiances, but if you want to use it for anything else, you’ll have to fake all relative position-dependant effects via game code, instead of using Studio’s 3D positioning system.
In general, I advise against using the scatterer sound module all together. We will fix its shortcomings in the future, but for now, it’s decidedly imperfect.
Wow, thanks for the info. I actually am currently using it for a few automatic weapons. Following your suggestion to use a loop region around a non-looping multisound, what would you recommend to allow the sound to play to its end when the loop is stopped? Stopping the event will kill the sound, and I noticed loop regions do not have the key-off cue release feature that sustain points do. The only other method I could think of would be to have a parameter condition which exits the loop region, playing the sound to it’s end. This seems less convenient than the cue release button though.
As for scatter sounds, You mentioned your intent to fix their behaviour in the future- since none of my project are going to be in any releases anytime soon, at least it’s something to look forward to!
edit: sorry Mike, for somewhat hijacking your thread.
The parameter condition is the recommended option, and once it’s established, it’s really no less convenient than a sustain point can be. There are alternatives (You could apply a AHDSR modulator with a long-ish release period to the master track volume, for instance, or just time appropriate end points in game code), but they tend to have undesirable side effects, or are more painful to implement and use than the parameter condition option.
We are planning to improve the way sustain points and cues work, so that you can have (for example) a sustain point that’s off by default and turns on when you need it, and we’re also working on some more advanced condition logic to complement the existing parameters and probability conditions already included, but these features are still a fair way off being implemented.
Awesome, thanks. I’m always looking forward to new features. I guess for the programmers, setting a parameter from 1 to 0 is no big deal. I’ll use that method instead to avoid the problems with scatter sounds.
Thank you so much for the speedy replies, both you. This was very helpful and informative. I’ve been using Designer for a while and now I’m switching over to Studio :]
And thank you Joseph in particular! I knew there had to be a smarter way to do what I was trying to do. Thanks a bunch!
If I’m understanding your situation correctly, you may be setting the pitch randomization in the event macro view of the deck. Make sure you’re setting the randomization in the controls of the scatterer sound itself. It’s right next to vol randomization, polyphony, and total sounds. The knob in the event macro area acts as a master for the entire event spawn.
Thanks for the detailed description of what’s happening; It’s quite clear what’s going wrong. Fortunately, there are solutions available.
You’ve already discovered one of the issues with your initial event design: Modulators take their cues from the module they’re attached to being triggered and untriggered, and not from anything else. This is working exactly as intended; It is consistent with how other modulation is applied to other sound modules, and many users desire this behaviour. There’s also a second problem that you’ve not noticed: FMOD’s pitch adjustment alters the speed at which a sound plays, so a looping multisound subject to any sort of pitch adjustment will have a longer or shorter interval than that baked-in to the wave length.
Assuming you’re working on the timeline, there’s a simple solution to both problems: Make the multi-sound module non-looping and create a loop region around it that’s precisely the right length to ensure the frequency of gunshot sounds that you want. Because the multi sound module will be triggered repeatedly, it will re-randomise the modulators each time, and the fixed length of the loop region will ensure that the rate of fire remains constant.
In your modified setup using event sound modules, the clicking you’re hearing is due again to the fact that Studio’s pitch modulation alters the speed at which a sound plays. Because of this speed change, the single sound modules you are using will occasionally reach the end of the waveform before the timeline cursor has left the trigger region. When this happens, the sound will play its initial section again briefly before being cutoff; This is the source of the hiccups you’re hearing. (Again, this is intended behaviour, though we do intend to make this kind of waveform length variability more visible in future.)
Again, there’s a simple solution: Instead of applying pitch modulation to the single sound modules apply it to the nested event sounds’ pitch macro controls. This will ensure that the playback speed adjustment corresponds to the rat at which the timeline cursor moves across the single sound module’s waveform, and so avoids the intermittent hiccuping you’ve been hearing.
Sorry if I’m out of place here, but… Would my recommendation not solve the root issue he’s having; he wants each and every shot to be pitch-randomized, not the entire event.
At least I think that’s what he’s trying to accomplish.
My above post assumed you were using multi sound modules, but RichardPGoulet suggests you’re using scatterer sound modules. I recommend you entirely avoid scatterer sound modules if possible; Their internal 3D panners tend to throw off distance- and direction-based effects if you’re not careful. Fortunately, the more common applications of the scatterer sound module can also be achieved using other module types.
