Hello, I’ve been doing some localization tests this week and I’m finding some aspects of the setup very limiting. What I’d like to do is setup multiple events using one audio table. Some of these events will be single voice lines, but others would have multiple speakers engaged in a conversation. The closest I’ve gotten so far is setting up the event using the new audio table instrument, like this:
The first thing that I wish I could do is commit the event auditioning key queue table to the event, so I don’t have to set these keys in engine. All I would need to do in engine is trigger the event. Is there any way we could force certain events to build with their auditioning key queue included? I think it would be incredibly useful and add a lot of flexibility if there were a button above the auditioning key queue to “Include key queue in build” or something similar, so that events could have a default key queue without anything needing to be set in engine. Alternatively, would there be any possible way to get a reference to that auditioning key queue when we trigger the event, that way we can just get an array of names from the event instance and use a for each loop to add those auditioning keys to the key queue at runtime?
The other issue that I’m running into is that it doesn’t seem like there’s any way to use audio table instruments with components but for the conversations mentioned above I also want to be able to use callbacks. Would it be feasible to make changes to the FMOD plugin to allow callbacks on normal event instances, or to get a reference to a component’s underlying event instance that way we could use audio table instruments and have callbacks? Ultimately, I think it would be nice to have more flexibility with how we approach localization and I really need to be able to use callbacks for some of the systems I’m planning for. We have alternative approaches we could take leaning more on the Unreal side of things, but I’d love to be able to do more of this stuff with FMOD instead.
Unfortunately, this isn’t something we currently support - but you’re not the first person to suggest it. I’ll add you to the list of people who’ve asked for this feature.
You could potentially store the list of keys as a user property? If you’re not familiar with user properties, you’ll find them near the bottom of the events browser when an event is selected. A user property is a variable associated with an event that can be read at run time and can hold a string.
User property is a great call. I’ll test that out this week.
Yeah I’ve been testing with Event Instance Add Audio Table Key, but that only works when I can grab a reference to the event instance, which as far as I know, I can’t do natively in blueprints using an FMOD Audio Component. But I think I have seen some forum posts on how to get that reference in C++, so I’m going to see if I can get that working this week. I’m just hoping to use callbacks from timeline markers with events that are using audio table instruments, otherwise we have to take a different approach to a feature in our game.
Hey Joseph, I wanted to follow up, because I did get this working, but using user properties still introduces an extra step with a lot more potential for human error. I was wondering if you’re able to comment any more about when or if we could expect to have some way of committing audition keys to an event? Would there be any world where this could also be done for programmer instruments?
I made another forum post about it here, but I’m running into issues when using multiple audio table instruments sequentially in a single event where I have no way to audition instruments later in the timeline without removing keys from the queue or listening to the entire event, so being able to build programmer instruments with their placeholder keys would solve that.
We use an agile development model in which both the scope and release schedule of future sprints is subject to change at short notice. While this gives us significant flexibility, it also means that our development roadmap is subject to change. As such, I’m afraid we cannot provide usefully-accurate predictions of when features will be released.
I suppose it’s possible… But I suspect we’re more likely to add the feature to audio table instruments first; and once it’s present in audio table instruments, adding it to programmer instruments as well would not provide much additional benefit.
I’ve added your feedback as a note in our tracker, so that we have your use-case for context when we begin working on the task.
