That parameter value now changes over the timeline, and you can see it changing in the nested event, but it doesn’t have an effect (e.g. you map it to volume in the nested event, you can see the parameter increasing, but the volume doesn’t change).
However, if you then use that parameter to control something in the parent event, that does work and you now have timeline automation for a parameter value. Really useful and I love that I can do this, but I’m wondering is this supposed to be possible?
I ask that because if it is then why can’t we just add a parameter automation directly to the timeline from the menu in the first photo, instead of needing this workaround?
To answer the question in the topic of this thread: No, you are not supposed to automate the value of a parameter instance on the timeline of the same event that contains that parameter instance.
Not being able to automate a parameter on the timeline of the same event that contains the parameter is a technical limitation of how automation works. Specifically, it’s because automating any property in an event implicitly adds an instance of the automating parameter to that event; and because timeline parameters, unlike all other parameter types, are unique to the events in which they are found and cannot be instanced in multiple different events.
Accordingly, FMOD Studio does not allow you to automate any property on the timeline if that property could potentially be instanced in other events… And the two categories of property that can be instanced in multiple events are the properties of shared effects, and parameter values.
There’s a few things to break down here, but the most important one is this: You’re not actually automating the value of the parameter on the timeline in this example. I know it seems like you are, but you’re actually automating “the property of the event instrument that sets the value of the parameter in instances of the referenced event spawned by that event instrument,” instead - and that’s an important distinction.
To put it another way, the property of the event instrument is not the same property as the parameter value in the referenced event. Rather, it’s a property that sets the parameter value property in each instance of the referenced event spawned by that event instrument. This extra level of indirection means that automating the property of the event instrument does not implicitly add an instance of the automating property to the referenced event, and so cannot cause a timeline to be illegally instanced in multiple events.
You are mistaken. Automating a parameter property of an event instrument does, in fact, have an effect - but that effect is isolated entirely to the instances of the referenced event that’re spawned from that particular event instrument.
This is because local parameters are instanced, meaning that a local parameter can potentially have a different value in every instance of every event that features that local parameter. When you automate a local parameter property of an event instrument, it sets the value of the associated local parameter only in the instances of the referenced event that’re spawned from that specific event instrument.
I’m not sure I understand what you mean. As I said above, you cannot automate a parameter on the timeline of the event containing that parameter. You can automate the parameter property of an event instrument n a timeline, but that only affects the value of that parameter in instances of the referenced event spawned by that instrument; it isn’t a workaround that allows you to automate the parameters of the parent event on the timeline of the parent event.
Thanks for this indepth explanation, that does clear things up a lot.
Just to clear up a couple of things I don’t quite understand I’ve made a quick video to hopefully show what I mean (this is 02.17 btw):
So when I said it didn’t have an effect I was relating this behaviour: the parameter changes but it doesn’t seem to have an effect on whatever it’s controlling. I’m not sure why the volume isn’t increasing here?
But now in the parent event I can automate the master volume from that parameter and it does work:
When I make a second parent + nested event with an identical setup, the volume now doesn’t change, which I presume is related to what you said about not allowing a timeline being instanced in multiple events?
Whatever is happening, this behaviour seems useful because I can use one lane of timeline automation to control a bunch of things in one event, which I don’t think is possible any other way without copying and pasting curves?
I’ve been able to reproduce some of those weird things, which seem to me like bugs. The nested event, when played alone, shoudn’t care of the timeline of the parent event. Furthermore, after “un-nesting” the event (“move to top level”), the timeline of the ex-parent event still seems to influence the ex-nested event, which makes absolutely no sense and confirms the bug in my opinion.
By the way, this brings up a question for me: why shouldn’t it be possible to control global parameters with an event timeline curve? Since the global parameters, if I’m right, are instanciated at a global level, this should be possible, shouldn’t it? Maybe I’m missing something, but it seems that this can only be done with command instruments (which are not as handy as curves), or with a trick (the same as EdGray talked about) by including a dummy instrument using that parameter.
I’m not sure why that volume knob is moving at all. Presumably it is automated on one or more parameters or has an attached modulator, but as you do not select the track in your video, its properties are not displayed in the deck for me to see.
The video not showing why it behaves this way also means I cannot tell you why that behaviour differs from your expectations.
I’m afraid I’m not sure which of the volumes in this example you’re talking about. Which of the four events are you auditioning, and which of the twelve volume properties in those four events are you observing not to change when you do?
Unfortunately, I have not been able to reproduce these issues when I test here. Could you please explain in more detail exactly what you’re doing to make them occur?
A local parameter can have a different value in each and every event instance that features that parameter. Timeline parameters are always local parameters, because they need to be able to have a different value in every event instance; if they couldn’t, it’d be almost impossible for a new event instance’s timeline to start at 0:00:000 when that instance starts playing.
A global parameter has only one value at a time, and that value is shared by everything that uses that global parameter.
If, hypothetically speaking, you were to to automate a global parameter on a local parameter (whether it was a timeline parameter or some other type), the fact that a local parameter can be instanced would make it possible for a global parameter to be automated by two or more different parameter values, each simultaneously automating the global parameter to have a different value. Since a global parameter can only ever have one value at a time, there is no good way to handle this situation. (We could hypothetically deal with a global parameter being automated to be two or more contradictory values, but the results would not be useful. We could take the average of the values a global parameter is automated to, for example, or ignore all but one of the local parameter instances automating it - but neither of those options would be especially intuitive, and the resulting global parameter’s post-automation value would often be so far divorced from the local parameters’ values as to seem entirely disconnected.)
Thus, we disallow automating global parameters on local parameters.
Command instruments can set global parameters because they issue a once-off API command to set the parameter’s value whenever the instrument triggered, rather than continually and continuously setting the parameter’s value on an ongoing basis as automation does. This means that it’s not possible for command instruments to send contradictory instructions; the commands are simply executed in the same order in which they were given.
I’m afraid I don’t understand how Edgray’s setup allows a global parameter to be controlled by a local parameter. It doesn’t seem to reference global parameters at all?
I’m very sorry for the lack of clarity in my previous posts. I’ve recreated that example I showed previously. I’ve also attached the projects to this post.
I’ll show a photo of all automation present in the project and then a video of the behaviour that, to me, seems to contradict your detailed explanation from your second post.
I don’t understand why, in both videos, we see the apparent volume going up, when the orange dot indicates that the actual value of the parameter isn’t changing.
I also don’t understand why in video 1b the automation in the parent event is still affecting the nested event, when I haven’t clicked through to it and have selected it independently from the browser.
I’ve removed the automation from the nested event, yet I’m able to use the existing automation to now control the master volume in the parent event. So, based on my understanding of your explanation, the “value of the parameter in instances of the referenced event spawned by that event instrument” is now automating something in the parent event based on the timeline in that same parent event? Is this not, then, a workaround to enable us to automate the value of a parameter in the timeline?
Example 3:
I’ve now duplicated the ParentEvent (and touched nothing else). Note that the timeline automation present in the original ParentEvent hasn’t copied over to the duplicated one:
Here’s how to simply reproduce the bug (FMOD 2.03.06, brand new project) :
Note that the point which triggers the bug seems to be to create the automation in the event instrument from “add curve” instead of the more usual parameter sheet.
However, it is possible to do so, by the method showed above (just change the parameter setting to global).
Thanks for the detailed reproduction information, both of you!
I’ve been able to reproduce the issue, and have determined that it is definitely a bug. It seems that when a parameter has been added to a referenced event implicitly (i.e.: by using it to automate a property in that referenced event or as a trigger condition for one of that referenced event’s instruments) and not explicitly (i.e.: by adding a parameter sheet to the nested event), attempting to add automation to the parameter property of the event instrument instead adds it to the value of the parameter.
This explains why the parameter of the nested event changes over time when you audition the referenced event on its own: The parameter property of the event instrument isn’t automated at all, yet the parameter itself is automated on the timeline, which is meant to be impossible. As a consequence, that parameter’s value will change over time in every instance of every event that features that parameter. This bug even makes it possible to automate global parameters on an event’s timeline, something which we do not support and will almost certainly result in unexpected behavior.
Thank you for bringing this issue to our attention. I’ve added it to our bug tracker, so it will be fixed in upcoming versions of FMOD Studio.
In the mean time, there’s a simple workaround to prevent this bug: Before adding automation to any parameter property of an event instrument, navigate inside the referenced event and add a parameter sheet for the parameter. This will ensure that when you subsequently add automation to the event instrument’s parameter property, it’ll be added to that property correctly instead of to the parameter itself.
That workaround will do nothing to “cure” automation added before adding parameter sheets to the referenced events, however; if your project features such automation, you will have to remove all automation from the affected parameters and recreate it from scratch.
Thanks for confirming, Joseph. The thing is, this seems to actually be quite a useful bug?
Here’s a scenario: I want a bunch of things in an event to have the same timeline automation.
With this bug then I can use one parameter to control all the things I want, then if I need to change the timeline automation I just have to change the one curve.
Without using this bug I’d have to copy and paste multiple timeline automation curves. Then if I needed to change the timeline automation, I have to copy and paste those curves all over again. If I wanted to quickly iterate over multiple variations of the timeline automation…forget it!
Being able to automate one parameter over the timeline that can then control multiple other parameters seems really useful and, please do correct me if I’m wrong, there’s no other way of doing it?
In fact, if the events you’re willing to control are nested or referenced, automating their parameters in the parent event will do exactly what you want. To avoid the bug, just add the parameters in the nested/referenced event as every normal person does : by adding a parameter sheet, not by adding it from the curve! You can, afterwards, edit the curve, either from the curve panel below, or the main panel.
If everything is right, when playing the nested event, no automation will apply (cause the nested event isn’t aware of what could possibly do the parent event!), but when playing the parent event, the nested event will play with the applied automation.
: by adding a parameter sheet, not by adding it from the curve! You can, afterwards, edit the curve, either from the curve panel below, or the main panel.