I’m currently trying to callback the tempo marker of either a nested or referenced event, at 0 or 1 depth level. I’m doing it via timeline_beat seen in the line below:
It works if the event I reference is just the actual event that has the tempo marker. Problem is, I have all music tracks referenced in a parent event that changes the music tracks randomly over time. Reading around the forums, it appears as though it should be possible to get the tempo marker/timeline_beat of at least 1 depth level. But I’ve tried 0 depth levels (the event isn’t nested, just referenced by dragging and dropping from the browser) and of course as nested. I’m on FMOD 2.01.07.
Here is a screenshot of how the parent event looks:
If you didn’t specify a type mask, then FMOD defaults to the EVENT_CALLBACK_TYPE.ALL mask, which should allow the EVENT_CALLBACK_TYPE.TIMELINE_BEAT callback type though.
Are you registering the callback with the parent event? If you just register it with the event description of the nested or referenced event, it won’t be passed to the parent.
It appears when we were adding better support for nested event callbacks, we chose not to enable beat callbacks. I believe the thinking was that you won’t be able to discern which event the callback is coming from if the parent or multiple child events have tempo markers, so the usefulness of the feature was in question.
However, we can look to add support for that in a future version.
Thanks for the clarification. I guess that is where the confusion stems from, the fact that other types of markers work in child events, but beat callbacks are exclusive to a single event. It would be very useful if you could pick which event (parent or child) it should do the beat callback from. I’m not sure if this could be done by checking if the parent event has a tempo marker or not. If it has one, it sends callback messages from that, but if it doesn’t, it goes to the next tempo marker it can find in any of the child events.
If there are multiple child events with tempo markers, I suppose it could pick whichever event is currently playing (that it would work with my example above with a multi-instrument hosting the child events.)
If the child events are playing simultaneously, it could pick the first one it finds, although I suppose this is a really specific use-case, and I can’t even see where you would want to use this, which goes back to your argument of the usefulness being in question.
But if you could at least discern between parent and “currently playing” child events, that would be great. The reason I’ve set it up this way is that the parent event controls the randomization and transitions between the child events. It cycles through the child events at random, then loops them. But the loop region has a 1% chance to disable itself, which will make the playhead go to Transition Marker A which sends it back to Marker A, picking a new child event and loops again.
This is much easier and more manageable than having a custom script that handles all this.
Regardless, until this feature goes in, if it even does, do you have any ideas about workarounds for this?
The only other way I can see this working would be doing something like having all the child events listed horizontally on the timeline and have a bunch of transition markers to jump between, but that is gonna get messy fast with transition markers. Then have a parameter that gets randomized from script and then set conditions of the transition markers to be hooked up to this parameter. Something along the lines of this:
