These are all very useful options. Apologies for the lengthy reply that follows!
I initially added
<<waitforaudio>> when I noticed that the tracks in the 2nd half of the project weren’t loading properly. Sound ran smoothly up to a certain point, and then it started to experience drop-outs, tracks not playing, etc. It was like the
StoryInit passage only had time to ‘read’ the first half of the
cacheaudio list (which is sequential for the project), before the land page loaded, and then never got around to loading/caching the second half of the list.
<<waitforaudio>> solved that, but at the expense of long loading screen lock before any passage loads. My aim is to either a) reduce the length of the loading screen lock, or b) let the user know there may be a loading time of up to a minute.
For b): The project has a series of landing and on-boarding passages, several of which occur before any audio plays. So, one solution could be to add
<<waitforaudio>> to one of them, and then on the link to that passage include a line of text like “may take up to a minute to load.” This was the idea behind my original question. Which sounds like it might be a solution, as long as no sound has been played up to that point?
For a): Because the
<<cacheaudio>> list is sequential for the project, and the sound ran smoothly up to a certain point in the project, I could try reversing the
cacheaudio sequence, and using
<<waitforaudio>> about halfway through. So essentially, I’m saying: make sure the tracks in the second half have loaded, then we can start. My concern would be I’d have drop outs in the first half of the project, but that could be tested.
I could also, as suggested, create groups and load the groups at specific stages in the story. I have a couple of questions around this. First of all, can I ask if there is a difference between
<<cacheaudio>>, and SimpleAudio.loadWithScreen() and
<<waitforaudio>>? Are the macros just simpler ways of executing the SimpleAudio commands, or is there a difference? (The warnings in the documentation made a little bit wary of using the SimpleAudio). If it’s just the same thing by another name, I could give it a try. Or, as suggested by the documentation, does SimpleAudio Load start downloading the tracks to the user’s device directly, as opposed to cacheing it in their browser?
Given that I’m basically trying to either let the user know to expect a wait as the project loads, or, reduce the lock screen time, or a combination of the above, which direction might be most useful and reliable: 1) moving
<<waitforaudio>> to a later passage, but before any sound has played; 2) flipping the sequence of the
<<cacheaudio>> list and placing waitforaudio in the middle, or 3) using the
SimpleAudioApi to group and load the groups as needed throughout the project.
Thanks as always, Ben