problems with events and loops

Hi. Firstly i’m new to FMOD but not new to audio production, so please bear with me if i don’t understand some specific to FMOD terms. I’m making my source material in LogicPro.

This is my first project in FMOD, so am probably doing things in weird ways, but i’m getting some strange behaviour with some ‘regions’ doubling up over each other - As in the playback starts but then starts again so i hear the audio twice but out of sync with each other by a bar. Also when it transitions back to [Intro] the A section keeps on playing over the top

I have a piece of music with 2 sections: [intro] and [A]. [Intro] always plays in full before auto transitioning to [A]. [A] can jump back to [intro] at any point but if not transitioning ought to loop continuously.

So [A] needs to loop, but i’m unsure whether to put the loop region around the actual nested audio or around the event on the main timeline. If i put it around the audio then playback is ok, but back on the top-level main timeline the region ends and cursor goes past the event still playing the music and subsequently past the transition region.
If i put the loop around the event on the top level, then i get the weird doubling and stuff.

Thanks in advance for any help and feel free to ask me any more specific questions.

I’m getting the weird doubling audio whether i put loop region on the audio or on the event

I think i know what’s happening, but i don’t know how to stop it.

The events are sustaining all the way to the end of the audio when it transitions to a new section. How can i turn this off?

The easiest way to “turn it off” would be to put an AHDSR modulator with a release of 0 on the event sound. That said, I think you would be better off not using an event sound for this particular bit of music, as it adds to your resource overhead; I recommend using time-locked single sound modules if possible, or a multi sound module with an internal loop region if not.

1 Like

Firstly, thanks a lot for the reply, i’m very relieved to have found this forum.

Yes, using an envelope works, thanks for that. However, it now needs the event to be as long as the loop (or the event cuts out) yet looping the event means that it doesn’t re-trigger at the beginning, the cursor goes back to the beginning but playback stops

I’m not sure what you mean by this, can you define ‘event sound’? I’m only using the one source file from the audio bin, i’m not duplicating any of my audio sources.

Ok, i’ve been reading up in the manual about time locked/non-time locked modules since i got this issue, i have a couple of things that i can’t make sense of that seem to relate to what you’re saying:

1, As i understand it, the only way to make a time locked section, is to have the actual waveforms at the very top level on the timeline ie. not nested and not a referenced event. The reason that i nested the events is twofold: firstly because i find it easier to manage stuff that is contained, in the same way that in logic/PT i ‘go into’ a region/clip to edit MIDI/audio events and then go back up a level to position and work with that region - possibly i am still thinking too much in a D.A.W way and need to adapt the way i work to FMOD - how do you keep sections manageable? Secondly and most importantly, i wanted two layers of automation because the A section contains two loops one with piano and one without, i’d set up a parameter to crossfade between the two loops and I wanted to apply further automation at the top level. For example, i wanted to fade out the entire [A] section while the crossfading parameter still worked independently. Hope that makes sense.

2, In trying to fix this problem, i switched from using nested events to using a referenced event and now the event seems to display some time locked features and some non-time locked features. For example when i stop and start playback, it picks up from the point where it stopped rather than re-triggering the event from the beginning - which i take as an example of time-locked playback. However, it also does the thing where it sustains the playback over transitions, which i take as an example of non time-locked playback. Can you shed any light on this?

Many thanks

Hmm, I’m not entirely certain what the nature of your problems is, so I’ll give you some background that seems related; Hopefully it will help.

You’ve probably picked this up from the manual… Modules are a basic unit of signal path design in Studio, and they come in a number of different types. Sound modules are one such type, and are defined as those modules that introduce sound to an audio track. Event sounds are one kind of sound module; Specifically, they’re sound modules whose signal comes from another event “nested” within the module. Because each active event sound module represents an entire event added to your project, they generally take up more system resources at run time than other kinds of sound modules. Admittedly, an event sound module is probably just a drop in the ocean, but thrift rarely goes amiss.

Different types of module act in different ways, but the trickiest distinction to wrap your head around (coming to Studio from D.A.W.s) is probably the difference between time-locked and time-unlocked sound modules. The difference is this: A timelocked sound module’s trigger region acts much like a D.A.W.'s track content does, but a non-timelocked module’s trigger region is an on/off switch. Which is to say, a non-timelocked trigger region doesn’t care how quickly the cursor is moving, whether it’s going forwards or backwards or standing still, or even about where on the trigger region the cursor enters and leaves; All it cares about is whether the cursor is inside or outside the trigger region at any given time.
Every trigger region has specific behaviour that occurs when the cursor enters it, and specific behaviour that occurs when the cursor leaves. These behaviours vary depending on module type and properties, but the “trigger” behaviour of an event sound module is to start its contained event, and its “untrigger” behaviour is to keep doing whatever it’s doing. As a consequence, the length of an event sound module’s trigger region on the timeline does not reflect how long that sound module will play for when triggered. Adding an AHDSR modulator to the module allows you to override and alter the trigger and untrigger behaviour somewhat.

It sounds like you could achieve your event design using a single event with single sounds, volume automation and track routing, but I can’t be certain; Could you please describe how you’ve currently set up the crossfade between the different sections of A? What quantisation are you using?

On an unrelated note, the stop transport button doesn’t actually stop an event’s playback; It pauses it. To stop playback entirely, you need to press it twice, or to hold it down for a few moments. (This has the side effect of returning the timeline cursor to the start of the timeline.) This might explain the behaviour you’ve seen where “stopping” results in playback continuing from where it left off.

I suspect I’ve missed at least some of your concerns; Please do ask follow-up questions.

I see, thanks Joseph, that’s very helpful re: time locked events. The only bit this doesn’t answer for me is the stuff about creating two levels of automation and general workflow, so if you can bear with me, i’ll go into that in a bit more detail.

I have an event on the list on the left hand bar to represent the [A] section, this is called [A crossfades] - see image. Within that event there are two different loops on two tracks, but playing in parallel and starting and ending at the same point - see foreground window in image. I created a parameter which x-fades between those two loops, one has slightly more intensity (piano, congas etc) so the idea being that the [A] section is mainly the same, but can vary in intensity by adjusting this parameter.

So together these two loops and the x-fade parameter make up the [A] section and i want that x-fade parameter to function regardless of other volume changes at a higher level, so i created a reference event of this [A] section event and added it to what i’m calling my ‘mushroom arrange’ event (listed on the left hand side - see image). Thus giving me an overall volume control for [A]

The reason i did this is because i find it easier to work on sections individually rather than having them all sitting at the top level (in this case ‘mushroom arrange’) and then reference those sections - kind of like working with files and folders, it would be hard to manage your computer if every file existed on your desktop. More importantly, i now have an independent automatable volume control for the entire A-section on the ‘mushroom arrange’ event, as well as the automated volume controls for [A] which i want to operate independently.

Like i said before i think i’m probably trying to force F-mod to behave like apple logic does and i need to get used to working in an F-mod way. If you could tell me where i’m going wrong with my thinking, that would be very helpful. Maybe if you could just explain a bit how you organise your music projects in Fmod, like do you write all the sections in one event tab (left hand bar list), or do you split them up into different event tabs like i’ve done with A and intro existing in separate tabs, then being referenced and arranged in a third tab (mushroom salsa).

Thanks again Joseph :slight_smile:

There’s nothing wrong with the workflow you’re using. When we were designing the interface for Studio, one of our goals was to make it fairly flexible, so that users can work in whatever way feels most comfortable to them. Sure, using event and event reference sound modules to organise your music has a resource cost, but it’s probably nothing to worry about; I just tend towards over-cautiousness - and you’re using event sound modules for exactly the purpose they were intended for, so there’s no problem there.

If the event is failing to re-trigger when the timeline cursor hits the end of its loop region, it’s probably because the loop region doesn’t extend beyond the ends of the event reference sound module’s trigger region; If the cursor doesn’t leave the trigger region, it won’t register as having re-entered it. If this is the case, your best option is probably to remove any AHDSR modulator from the event reference sound module, turn off snapping, and manually resize the event reference sound module’s trigger region to be a infinitesimal distance smaller than the loop region; Then, turn snapping on again.

Other than that, I think you shouldn’t have any problems so long as the length of the event sound module in “mushroom arrange” matches the length of the sound modules in “A crossfades” and the events don’t include any pitch adjustment*.

Personally, I try and keep all of a piece of music in a single event, since I like being able to use a single timeline as a constant reference; That’s just me, though. As I said, this is more about preferences than best practices.

  • Pitch adjustment, in FMOD, alters the time it takes for a sample to play to end, and, if applied at the event level, the rate at which the timeline cursor moves. As a result, pitch adjustment can cause music to get out of sync if not carefully compensated for.

Thank you Joseph. It’s good to know I’m not going completely down the wrong path, especially in these early days of learning the software

Actually, If i may, i’d like to ask you one further question relating to these issues.

So my crossfades bit uses a parameter control, which is on a different level to all the other parameter controls (for transitions). Is that likely to cause a problem when linking to a game?

I ask because i notice that i can’t actually access that parameter during playback. If i click on the crossfades reference link in mushroom arrange while the music is playing, it opens the window for the crossfades section, but it’s not active as in the cursor is not moving and changing the x-fade parameter has no effect.

This also means that i can’t audition how my transitions are going to sound in all cases, because the reference event for crossfades, only ever plays with the x-fade parameter all the way to the left.

So is there any way to get access to that parameter from the top level? Or more importantly, is this likely to be a problem when trying to link to a game (I am completely in the dark about the process of actually linking to a game). It seems like maybe referenced events only really work if they’re static parts at the level you’re referencing.

Multiple instances of any single event can be active at the one time. This is to enable, for example, the same “dancing flower” event to be used for every dancing flower that appears in a game. With event reference sound modules and some other module types, it’s even possible for multiple instances of the same event to be created by a single parent event. Studio takes this into account, and that’s why the properties you see when you double-click on an event reference sound module don’t update as the parent event auditions: The parent event is playing a different instance of the referenced event to the one that’s displayed in the event editor.

To alter the properties of a particular event instance, single click on the event reference sound module’s trigger region to select it (if the event editor displays the content of the referenced event, you’ve double-clicked by mistake), and adjust the parameter value knobs shown in the deck. (Technically this will alter the parameters of every instance of the referenced event triggered by that particular trigger region, but that’s only relevant in events where the a trigger region can be retriggered before its content comes to an end.) You can even automate these knobs, and thus tie them to the parameter values of the parent event. As an alternative to automating, the parameters of referenced and nested event instances automatically update their values to match identically-named parameters in their parent events. In short, updating a nested or referenced event’s parameters in-game shouldn’t be an issue.

Incidentally, you can set the initial value of a parameter to be used by instances of that event when they start by right-clicking on the parameter knob and selecting “Set as Initial Value” from the context-sensitive menu.

Oh, and the “HOLD” parameter property allows you to specify that the parameter value shouldn’t be updated by its parent event after the event instance starts, which can be useful for some kinds of content.

Ah, fantastic. Thankyou Joseph. I hadn’t noticed that the parameter appears in the deck on the referenced event :slight_smile: