For complex projects, it may be useful to have A2S programs triggering loading (compiling with offline rendering etc) of A2S modules. Currently, this calls for application side code, which precludes using A2S for glue scripting of anything other than synchronous, blocking operations.
One use case for this would be to load/render sounds, soundscapes, songs and the like incrementally, rather than doing it all up front.
To do this, we need to figure out how to spawn worker threads, how many of them to spawn, and how to deal with synchronization around the master state. It's either that, or having the API context do it - but then we'd have to piggy-back on "unrelated" API calls, or rely on applications calling a2_Run() or similar regularly from a suitable context.
olofson
commented
10 years ago
For complex projects, it may be useful to have A2S programs triggering loading (compiling with offline rendering etc) of A2S modules. Currently, this calls for application side code, which precludes using A2S for glue scripting of anything other than synchronous, blocking operations.
One use case for this would be to load/render sounds, soundscapes, songs and the like incrementally, rather than doing it all up front.
To do this, we need to figure out how to spawn worker threads, how many of them to spawn, and how to deal with synchronization around the master state. It's either that, or having the API context do it - but then we'd have to piggy-back on "unrelated" API calls, or rely on applications calling a2_Run() or similar regularly from a suitable context.