We seek for possible UI integration for AAP, and for aap-juce it used to be planned to build wasm-based UI using juce_emscripten. It was then abandoned because Android Chrome did not support Atomics (and SharedArrayBuffer). They are now on Android Chrome (needs some feature flags enabled) so it is technically possible again.
It is only an initial draft but the basic out-process UI integration strategy is outline at https://gist.github.com/atsushieno/eb8155cbde052ded330ff9667b51e937 . To make it happen on aap-juce, there will have to be some injection wherever AudioProcessorEditor accesses AudioProcessor. It is likely that we have to patch plugin apps code to have intermediate AudioProcessor that taps into call to AudioProcessor API uses by the editor, if that is possible and sufficient. Needs some experiment.
context: https://github.com/atsushieno/android-audio-plugin-framework/issues/34
We seek for possible UI integration for AAP, and for aap-juce it used to be planned to build wasm-based UI using juce_emscripten. It was then abandoned because Android Chrome did not support Atomics (and SharedArrayBuffer). They are now on Android Chrome (needs some feature flags enabled) so it is technically possible again.
I have updated my own fork of juce_emscripten at https://github.com/atsushieno/JUCE/tree/juce_emscripten_607 so that it may be usable. There is no CMake integration yet though.
It is only an initial draft but the basic out-process UI integration strategy is outline at https://gist.github.com/atsushieno/eb8155cbde052ded330ff9667b51e937 . To make it happen on aap-juce, there will have to be some injection wherever AudioProcessorEditor accesses AudioProcessor. It is likely that we have to patch plugin apps code to have intermediate AudioProcessor that taps into call to AudioProcessor API uses by the editor, if that is possible and sufficient. Needs some experiment.