Idle Vs. Event Trigger Modifiers
© Brennan Young 2000
Quicktime will take the time it takes for your sprites to process its idle messages, which can slow everything down. For more accurate synchronisation, use an event modifier to trigger a custom event instead. Event trigger modifiers can not improve performance on slow hardware, but your custom event will be called at a more solid pace. If the processor is overstressed, Quicktime will (as is well known) 'drop frames', so you might lose a few events. The events you do get, however, will be accurately timed.
Considering that idle events are sent regardless of the movie playback rate, one possible disadvantage of Event Trigger Modifiers is that they are locked to the timeline of the movie, and only work when the movie is playing. They are also affected by the playback rate in a way that idle events are not, but this in itself can be a feature; For example, if you made a drum machine using the Quicktime musical instruments, you could use an Event Trigger Modifier to synchronise the beats, which would be very accurate, then changing the tempo would be as simple as changing the rate of the movie playback with SetRateBy
Setting up an Event Trigger Modifier
Event Trigger Modifiers are a very powerful synchronisation tool, but are difficult to understand. Sprites can receive events from modifiers by assigning the modifier as the 'Source' of events in the sprite's Scripts tab. Make sure that you have created a custom event and pay attention to its ID. It's better to give the custom event an ID which you are comfortable with, like 100 or something. The automatically generated IDs can be a little wild!
When you make your event trigger modifier, there are three essential parameters to consider, the rate, measured in frames per second, the repeat, and the sequence itself.
Let's assume we have a sprite sample whose duration is 1 second, and we want to trigger the event with ID 100 twice every second.
The settings we want are:
Rate: 4fps
Repeat: 2
Sequence: 100 0
Event trigger modifiers work on the priniciple of 'deltas', or data change. This means that we need to put '100 0' in the sequence, so that there is a change from one trigger to the next. In other words we use the 'dummy' value 0 to register the change from one value to the next. This means we need to send events twice as often as we might expect, because every second event is a dummy.
One value from the sequence is sent as an event every 'frame', and the sequence needs to be repeated twice because there are two values in the sequence, running at four frames per second in the modifier and we want it to last for 1 second in total.
All in all, this means that the event 100 will be sent twice every second, as long as the processor does not get too stressed. Here's a little table to help you understand how this works with different settings:
| Rate | Repeat | Sequence | Events of ID 100 sent | Modifier Duration |
| 2 fps | 1 | 100 0 | 1 per second | 1 second |
| 4 fps | 2 | 100 0 | 2 per second | 1 second |
| 6 fps | 3 | 100 0 | 3 per second | 1 second |
| 8 fps | 4 | 100 0 | 4 per second | 1 second |
| 8 fps | 40 | 100 0 | 4 per second | 10 seconds |
| 1 fps | 30 | 100 0 | 1 every 2 seconds | 1 minute |
| 2 fps | 60 | 100 0 | 1 per second | 1 minute |
Of course, you can always have more than two values in your modifier sequence, and you don't necessarily need a dummy value if you want to send two different events alternately.
back to