New in 2019.1 - Timeline Signals

[julienb]

Since Timeline released in 2017.1, there has been a lot of [requests]( Timeline events? page-2#post-3313335) [for]( Timeline events? page-3#post-3366709) [events]( Timeline events? page-4#post-3598074). With good reason; it was something that was sorely missing. Some people implemented events through clips (by the way, thanks to everyone who offered their custom event implementation to the community), even if, in this use case, clips had their shortcomings.

Well, the Timeline team is proud to offer you an early Christmas present: signals are now available in 2019.1.0a11!

A new item has appeared: markers!

A marker is new item that can be added to a timeline. It is used to represent a point in time.
Markers can be added and manipulated on a timeline the same way as clips; selection, copy-paste, edit modes etc. should work. A marker also has a specialization, just like clips (Animation Clip, Activation Clip, Control Clip, etc.). In 2019.1, Timeline offers its first built-in marker: Signal Emitter marker.

What are signal emitters?

Signal emitters are used to trigger a change in state of the scene when the timeline passes a given point in time. We used the word signal instead of event because it supported the idea of “broadcast” while avoiding the confusion with the already existing Unity Event and Animation Event.

Where can I add a Signal Emitter?

A Signal Emitter can be added on the timeline and on tracks (with some restrictions).

• On the timeline: This is a new concept for this release. Signals can be added on the timeline itself. No tracks are needed in this case.
• On a track: Signals can also be added to any track, as long as the track accepts a binding. We’ve also introduced a new type of track, a Signal Track. This track accepts only signals but no clips.

Keep in mind that where you place a signal emitter will define how this signal is received. More on that later.

How does it work?

In order to properly set up signals on a timeline, you need three pieces: a Signal Asset, a Signal Emitter and a Signal Receiver.

• Signal Asset: This asset is the link between an emitter and a receiver. Basically, the Signal Asset acts as an identifier.
• Signal Emitter: A Signal Emitter is placed on the Timeline. It contains a reference to a Signal Asset. When played, if the current time is greater than the emitter’s time, the emitter is triggered; it will send its Signal Asset to a Signal Receiver.
• Signal Receiver: The Signal Receiver is a component that has a list of reactions, each of those reactions are bound to a Signal Asset. When a receiver is notified that a signal has been triggered, it will invoke the reaction bound to the corresponding Signal Asset.

The main idea that guided our design was to make the piece that sends the signals (the emitter) as independent as possible from the piece that listens and reacts to signals (the receiver). This design adds a lot of flexibility and is very powerful. Let’s see in details how all those pieces work together.

The Signal Emitter

• Create a timeline. Then, click on the pin button near the edit modes button.

• The Timeline Marker area is now displayed. Right-click in the area under the time ruler and choose Add Signal Emitter.
  

• In the Signal Emitter inspector, click on Create Signal… to create a new Signal Asset to your project.

• Still in the Signal Emitter inspector, click on Add Signal Receiver. The inspector should look like this:
  

The Add Signal Receiver button did the following:

• It added a new Signal Receiver component to the bound object. If the Signal Emitter is on a track, the component will be added to the track’s bound object. If the Signal Emitter is on the Timeline (like I did in my example) then the Gameobject which owns PlayableDirector will have a new Signal Receiver component.
• It added a new reaction bound to the Signal Asset I just created.

I can then use the Unity Event UI to define what should be invoked when the Signal Emitter is triggered.

The important part is that the Signal Emitter inspector first shows you properties related to the Signal Emitter. It also displays, for your convenience, the Signal Receiver that will receive the signals.

The Retroactive property, when enabled, will trigger the signal if the timeline begins playing after the signal’s time.
The Emit Once property, when enabled, will trigger the signal only once when the timeline loops.

The Signal Receiver

Let’s take a look at the Signal Receiver component. Click on the Gameobject that owns the Signal Receiver.

It shows you nearly exactly what we saw previously; the Explosion signal is bound to an empty UnityEvent.

Let’s say we want to add a new Signal Asset. We can do it right here. Click the Add Reaction button. A new reaction was added, bound to nothing. Click on the dropdown and choose Create Signal…

Here is my result after I created a new asset:

The Signal Receiver is now setup to invoke reactions when it receivers the Explosion and Load Scene signals.

If I go back to the Timeline, then I can add a Signal Emitter that either sends the Explosion or the Load Scene signals. I can also easily switch between the two.

So in a nutshell, how do I setup my first signal?

You need a grand total of 4 clicks:

• Right-click on a track which supports signals, then choose Add Signal Emitter
• In the Inspector window, click on Create Signal Asset, choose a file name and hit Enter (one less click :p)
• Still in the Inspector, click the Create Reaction button.

That’s it! In the Unity Event UI, you can setup what is necessary for the reaction associated with the signal you just created.

Can I create my own markers/signals?

Yes, you can. See this thread: New in 2019.1 - Marker Customization

I’m finished! It was a long wait, but we hope it was worth it. Enjoy!

[u7pp]

Sweet!!! I was worried this was dropped from the roadmap.

[julienb]

You can also check this video that will give you an idea of what is possible with signals:

Timeline - Signals

[AndrewKaninchen]

Having signals be empty objects seems counter-intuitive to me. Shouldn’t there be, by default, a way for signals to have information embedded in them?

Say I wanted to have a Timeline with multiple explosions, to go in line with your example. But say I also wanted all of those explosions to be slightly different. Would I need to create, for every explosion, a different signal?

And then, worst of all, whenever I created any other Timeline, would all those signals be shown in their dropdowns, even if they have nothing to do with those signals at all? This last part seems to be easily solved, at least in the abstract, by embedding Timeline and Signal objects in their Scenes instead of their own separate assets. That way everything that matters could be referenced easily and you wouldn’t fill you dropdowns with an endless number of useless things.

But really, even having to create multiple signals for basically the same thing in the same Timeline bothers me conceptually. I’d very much rather have the marker itself be responsible for the parameters used by the Emitter, or whatever other abstraction which would allow me not to need creating a million Signals for very simple things.

Markers, Signals, Emitters and Receivers being 4 separate things looks like a lot of overkill to me and kind of seems to break the purpose of having everything that happens neatly packed in a timeline. I think I understand the wish to have decoupling from Scene references into Assets (it’s something that comes a lot into my mind), but it’d be much better to have it be an option, not a necessity.

[Vectrex]

Great job. I like the decoupling of actions.
Andrew: If you wanted that you could just make a custom script and control the randomness from normal variables etc.
I presume, since it’s UnityEvent the timeline can also pass variables into function calls, which would allow it to control complex functions without having to hack in programming like functionality into timeline.

[AndrewKaninchen]

@Vectrex

Great job. I like the decoupling of actions.
Andrew: If you wanted that you could just make a custom script and control the randomness from normal variables etc.
I presume, since it’s UnityEvent the timeline can also pass variables into function calls, which would allow it to control complex functions without having to hack in programming like functionality into timeline.

The idea is not randomness, it’s actually quite the opposite.

Basically, I don’t want to have to create a different Signal Asset for every single set of slightly different function calls. It would pollute the signal dropdown stupidly fast.

[Vectrex]

Ok, I assumed it worked like the Animation events, where you could call any function and EACH call could have unique parameter values passed through. It seems like this doesn’t do that.

Also these functions work except the multi-parameter ones. Which I think should be supported. The old events only took one and it was quite a hassle.

    public void DoThings()
    {
        print("DOthings");
    }
    public void DoThings2(int num)
    {
        print("DOthings "+num);
    }
    public void DoThings3(string str)
    {
        print("DOthings "+str);
    }
    public void DoThingsGO(GameObject go)
    {
        print("DOthings "+go.name);
    }
    public void DoThings4(int i, string s)
    {
        print("DOthings");
    }
    public void DoThings5(int i, string s, GameObject go)
    {
        print("DOthings");
    }

It appears that each keyframe shares the parameter values with the Signal file? I was wondering why he created two signals for each foot, when I assumed it’d be just adjusting the parameter values passed to the function.

Trying to set the 3 keyframes to different values failed for me.

[JakubSmaga]

Shouldn’t the Timeline .playable asset hold all of the signals instead of us having to create and save each signal asset inside the Assets folder? Because for me it looks like the whole signals system just isn’t how it should be done.

[hippocoder]

Thanks a lot for the pressie - I think we might have to start making moves toward timeline integration now.

[julienb]

See this thread to know more about marker customization: New in 2019.1 - Marker Customization

[AndrewKaninchen]

@julienb

See this thread to know more about marker customization: https://discussions.unity.com/t/724249

The example project in this thread is exactly what I was talking about! Shouldn’t something more like that be offered as default behaviour alongside the signal stuff? I can see it’s mostly quite simple stuff to implement by yourself if you know what you’re doing, but not having this as a built-in and recommended way of doing it only serves to preemptively destroy any possible consistency between projects.

[andybak]

@JakubSmaga

Shouldn’t the Timeline .playable asset hold all of the signals instead of us having to create and save each signal asset inside the Assets folder? Because for me it looks like the whole signals system just isn’t how it should be done.

At first glance it does seem a tiny bit over-engineered… A bit ‘enterprisey’…

[Kiupe]

Sounds interesting.

Can an SignalAsset be extended in order to add it properties that can be retrieved by a SignalListener ?

Does that mean that with the current workflow only one SignalReceiver can be “bind” to a SignalAsset ?

There were a lot of videos and hype about ScriptableObject to handle properties and events - it would have been cool to have a SignalAsset to be like this - meaning be able to trigger when the SignalEmitter is “consumed”. SignalReceiver could simply registered to the SignalAsset. It would allow to have more than one SignalReceiver “listening” to a same SignalAsset.

Thanks

[starikcetin]

Yay Adobe Flash!

[andybak]

@starikcetin

Yay Adobe Flash!

Lol. I must admit to sometimes missing timeline based style of development. It became unfashionable in the same way VB6 click and drag dev did - for some good reasons - but you can’t beat it for speed and convenience and accessibility.

[julienb]

Thanks for the precise and thoughtful feedback, it is very appreciated. I know I took a while to respond; we talked a lot about your feedback internally.

@AndrewKaninchen

I understand what you mean. We seriously thought about having a built-in message system in Timeline, but decided against it. Let me backtrack a little bit.

When starting the Timeline Events feature, we saw early on that there are two main ways to implement events: Messages and Signals. The first one has all the data on the caller side, like Animation events. On the other hand, Signals let the callee manage what to do. Both have very valid use cases and both also have different setups. We decided to take the direction of Signals for the following reasons:

• Flexibility: The decoupling between the emitter and the receiver enables a lot of use cases.

• Reusability: Multiple timelines can use the same set of signals.

• Multi-user workflow: The signals system can let one user create a set of signals and receivers. Another user then has a list of predefined signals that can be used to build a timeline. Having the signal assets independent of the timeline asset helps tremendously when working with big teams.

• Ease of use: We saw that having all the reactions in the same object (the receiver) makes it easier to debug. It is also easier to follow what’s happening in the timeline because there is a clear separation between who reacts and who triggers a reactions.

We strongly believe that the Signal system is the best way to trigger events in Timeline; we think this is what users should strive for, once the initial hurdle of understanding the three piece workflow is gone.

It’s a tough balancing act for sure and that system may not please everyone. Using the Playable’s Notification API, it is possible for users to implement their own version, tailored for their workflow and their game if the built-in version does not fit. We also plan to release a package with code examples for Timeline (like an updated version of the Default Playables from the Asset Store), which will contain new types of markers, so that you can take those and reuse them.

@AndrewKaninchen

Having signals be empty objects seems counter-intuitive to me. Shouldn’t there be, by default, a way for signals to have information embedded in them?
Say I wanted to have a Timeline with multiple explosions, to go in line with your example. But say I also wanted all of those explosions to be slightly different. Would I need to create, for every explosion, a different signal?

Signals Assets are just an id; they are the link between an emitter and a receiver. In your example, yes, you would need a different signal for a each different explosion. In our design, the role of the Timeline is to say “a big explosion happened’’ and it is up to the scene objects to react to that and to activate the correct subsystems (particle, audio, etc.) with the correct parameters.

@AndrewKaninchen

And then, worst of all, whenever I created any other Timeline, would all those signals be shown in their dropdowns, even if they have nothing to do with those signals at all?

You are right, it is an issue; the dropdown could fill the whole screen height and it is hard to search for the correct signal in that case. We’ll address that for sure.

@JakubSmaga

Shouldn’t the Timeline .playable asset hold all of the signals instead of us having to create and save each signal asset inside the Assets folder? Because for me it looks like the whole signals system just isn’t how it should be done.

We want users to be able to reuse signals between different timelines and to be able to create signals even before the timeline itself exists. Having signal assets embedded in the Timeline itself removes the ability to do that.

[julienb]

@Kiupe

Can an SignalAsset be extended in order to add it properties that can be retrieved by a SignalListener ?

Yes, SignalAsset can be extended. If you want to add properties that will be picked up by the receiver, you can do so. However, you will also need to write your own receiver. You can also extend SignalEmitter to add custom data if you want.

@Kiupe

Does that mean that with the current workflow only one SignalReceiver can be “bind” to a SignalAsset ?

No. You can have multiple receivers bound to the same SignalAsset. Also, let’s say you have a track that has a binding and signal emitter. If you put multiple receivers on the bound object, all the receivers will receive the signal.

In my example here, both Signal Receivers will receive MySignal.

[andybak]

Signals Assets are just an id

then

We want users to be able to reuse signals between different timelines

I might be misunderstanding here - if signals are just an ID then what’s the benefit in enabling reuse?

[julienb]

@andybak

Signals Assets are just an id

then

We want users to be able to reuse signals between different timelines

I might be misunderstanding here - if signals are just an ID then what’s the benefit in enabling reuse?

Let’s say you have a signal Asset Explosion in your project and you a receiver in the scene that reacts on the Explosion signal. Any timeline can send the Explosion signal; you can reuse that signal in multiple timelines. If the receiver is correctly set up, it will receive the Explosion signal, regardless of which timeline sent it.

Concretely, it lets users work on multiple timelines at the same time while still using the same set of signals.

[AndrewKaninchen]

@julienb , thanks for the response, even if it took some time.

I do understand the advantages of the system and, given that you agree the dropdown problem is a thing and plan to solve it, I do agree it’s the best overall approach.

What I still don’t like about it, though, is the fact that it is obligatory. There are usecases for embedded signals and messages. Most signals I can think of actually make more sense if embedded in a Timeline. What I think should be possible is the choice between embedding them or not, and the ability to Convert between them automaticaly, kinda like how Bolt allows you to do between Embed or Macro sources.

And the thing is, the workflow around it would not even differ a lot. It’s just a matter of allowing Signal Assets to be embedded into Timeline Assets and have Signal Emitters and Receivers choose between a “global” list of signal assets or the one from inside the TimelineAsset itself (in the case of Emitters) or a given Timeline Asset (in the case of Receivers).

If you started using an embedded approach for simplicity and later decided to give the event for someone else to work on while you are still working on the Timeline, a simple “Convert” button would give you the dialog to create the Signal Asset outside of the Timeline Asset and fix all references on emitters and receivers to follow the new approach.

The same thing could actually apply to Timeline Assets themselves, and to most other asset dependent approaches, like Post Processing Profiles or Animator Controllers. These don’t have much of the same problem as Signals are bound to have, as the amount of assets you create for each type is probably not that big for any given project, but to have that extra bit of control would be marvelous for dealing with huge amounts of single-use assets.

I don’t know how you would solve the dropdown problem, but I do think this is a good direction for it. It’s not direct messaging, which would still be nice for the simplest of things, but it doesn’t complicate the system any more than it should. I’d argue it even simplifies it. And it would be compatible with other ways to aggregate Signal Assets.

Well, I think that’s all I have to say for now.