I've tested this by adding a sleep (30) inside the liquidsfz loading code. Instrument changes while busy loading another instrument are no longer lost now, and the event queue gets unconditionally processed, although two branches are necessary since in one branch (when the loader is busy) we cannot access synth_.
One issue that I noticed while implementing this is that currently the code uses sem_.post() (which is effectively sem_post()) to wake up the loader thread from the audio thread. I am not sure if this is hard RT safe, and if not, if we already have some kind of alternative available that is hare RT safe.
See also #44.
I've tested this by adding a sleep (30) inside the liquidsfz loading code. Instrument changes while busy loading another instrument are no longer lost now, and the event queue gets unconditionally processed, although two branches are necessary since in one branch (when the loader is busy) we cannot access
synth_.One issue that I noticed while implementing this is that currently the code uses
sem_.post()(which is effectivelysem_post()) to wake up the loader thread from the audio thread. I am not sure if this is hard RT safe, and if not, if we already have some kind of alternative available that is hare RT safe.