Magnetic Transition Markers

Just updated to FMOD 2 and am really loving the new magnetic regions.

Is there a reason Destination Markers can’t be magnetic too? That we we could do away with transition regions in a lot of events.

1 Like

Markers, unlike regions, only occupy a single point on the timeline. This means that if a destination marker was magnetic, the playback position would get caught in a loop of jumping to the marker, immediately moving off it, and then immediately jumping back onto it again. Such loops require the FMOD scheduling system to do unnecessary extra work, and also cause the playback position to jitter in a way that is not useful for sound design.

“Magnet markers” would provide no functionality that can’t already be achieved through the use of magnet regions. You’re right that you can do away with transition regions in a lot of events, but you can already do that with magnet regions alone.

Yeah okay fair play to that first point. Thanks.

I’m a little confused about the second, though. Is it possible to use a magnetic region as a destination without looping within it’s boundaries?

To @vincentoliver’s point, I could see the use for magnetic markers. For example, an ending stinger of a music event would be slightly tidier than using a transition region to a marker. The introduction of magnetic regions did help us get rid of excess transition regions, after all.

In a recent project I resorted to using transitions instead of magnetic regions, and a magnetic marker would have solved the problem. I had a track with sections A, B, C, etc., and if I jumped to section C from anywhere, I wanted the track to continue on to section D then E and so on rather than looping section C. Now that I’m writing this though, I realize I could’ve tried testing parameter-setting command instruments with a quantized interval at the end of each section.

As for a hypothetical magnetic marker continuously trying to pull the playhead back to it infinitely, maybe an option could be created in magnetic regions or markers to “fulfill” the call when returning to it. This might make for some weirdness when the playhead crosses another mag region while the parameter is still defining another value, but could be resolved by having an option in magnetic regions and markers to SET a parameter to the value of itself when crossing into its bounds.

Magnet regions technically don’t loop within their boundaries. Rather, whenever the playback position is outside of an active magnet region, the playback position jumps to a point inside that magnet region. This does superficially resemble looping within the magnet region in the some cases, but if (for example) the magnet region is quantized and does not end exactly on a quantization point, the playback position may leave the magnet region and remain outside it for some time before jumping back inside, and if the magnet region has an offset mode other than “none” and there are other magnet regions in the event, the playback position may jump to a point other than the start of the magnet region.

In any case: To stop the playback position from jumping to a magnet region, you must ensure that magnet region is not active by ensuring its trigger conditions are not met.

This could be tidied up as effectively with a magnet region as with a magnet marker.

A magnet marker would not have helped in this case. As I mentioned earlier, magnet regions (and by extension, magnet markers) cause the playback position to jump to their position whenever their trigger conditions are met. This means that if you used a magnet marker to jump to section C, the playback position would not continue on to section D or E until the marker’s trigger conditions stopped being met. In fact, this would actually be worse than using a magnet region, as the playback position would jitter on and off the magnet marker until the marker’s conditions stopped being met, causing stuttering playback if you were using synchronous instruments.

This is an interesting idea, and could potentially be useful for other marker types as well. There would need to be a way of resetting such a marker to allow it to be used again, of course, and it would require the addition of some new trigger condition behaviors… I’ll add this suggestion to our feature/improvement tracker.

1 Like

Thanks for the info, Joseph. Still getting used to these things!