Questions et réponses de la communauté

Bienvenue sur le forum de questions et réponses d'Audiokinetic, propulsé par la communauté. C'est l'endroit où les utilisateurs de Wwise et Strata s'entraident. Pour obtenir une aide directe de notre équipe, veuillez utiliser la page « Tickets de soutien ». Pour signaler un bug, utilisez l'option Bug Report dans l'Audiokinetic Launcher. (Veuillez noter que les rapports de bug soumis au forum questions-réponses seront rejetés. L'utilisation de notre système de rapport de bug dédié garantit que votre rapport est vu par les bonnes personnes et a les meilleures chances d'être corrigé.)

Pour obtenir rapidement les meilleures réponses, suivez ces conseils lorsque vous posez une question :

  • Soyez précis : qu'essayez-vous de réaliser ou quel est le problème spécifique que vous rencontrez ?
  • Pensez à inclure les détails importants : incluez des détails tels que les versions de Wwise et du moteur de jeu, le système d'exploitation, etc.
  • Expliquez ce que vous avez essayé de faire : indiquez aux autres les mesures que vous avez déjà prises pour essayer de résoudre le problème.
  • Concentrez-vous sur les faits : décrivez les aspects techniques de votre problème. Se concentrer sur le problème aide les autres personnes à trouver rapidement une solution.

+3 votes
I am using the "Limit sound instances to 1" on my Music Containers to avoid multiple Music tracks to play on top of each other if the player crosses the trigger multiple times. (As detailed in the following Q&A: https://www.audiokinetic.com/qa/19/how-to-ensure-there-is-only-one-instance-of-my-loop-playing)

However, it seems that Wwise requires the Sound instances limit be set to a higher number for it to process the loops correctly (especially using pre-entry and post-exit points).

How can I achieve both of these behaviors at the same time?
dans General Discussion par Antoine V. (180 points)
I would also love to know about this.

1 Réponse

0 votes
This is a difficult issue and one that I have experienced. The solution I am about to explain, I have not tested, though I will be using it soon to see.

The solution is to implement the music as if it is one long chain of switch changes. The "play music" event only ever happens once and it's at the beginning of the game. When new music is required, the switch is changed. The benefit is that, if the interactive music engine is already on switch A, and receives an event to go to switch A again, it does nothing.

 I'm guessing that your trigger has a play action in the event. Can you change the event to use a switch instead?
par Daniel Beck (390 points)
Hi Daniel,
Thanks for your answer!
This makes sense and seems to be a viable solution.
The only problem I could foresee with this, is that since we're already using states to dynamically change the music following various in-game events, adding another switch container to direct area-related music changes might be a bit convoluted. I'm especially wondering if that's the most memory-friendly solution!
Yup, Daniel's answer is solid, and this is how music in Wwise should be structured. One master play action, and switch to different playlists.  
Memory is usually never a concern with music since it is streamed.

Thanks for posting, Daniel!
Great, thanks! I've already started setting up this method, however, I'm encountering some problems related to transitions when using pre-entries.

When the Source Segment contains a pre-entry, the "Exit source at: Immediate" doesn't work as it should, it instead waits until the pre-entry is done playing before switching.
This creates a problem as the source's pre-entry will continue playing on top of the destination segment.
Furthermore, if the switch is set again to its originale value, the same pre-entry segment will be triggered again (on top of the last one if it had not done playing).

Is there any way around this? Thank you!
...