Git Product home page Git Product logo

aap-juce's Introduction

AAP-JUCE: JUCE audio plugin and hosting support for AAP (Audio Plugins For Android)

This repo is the place where we have the common JUCE integration support modules for aap-core (AAP), for both plugins and hosts.

The entire AAP framework is on early development phase and not ready for any serious consumption yet. Everything is subject to change. Contributions are welcome but please bear in mind, documentation is poor and source code is ugly yet. We have GitHub discussions for AAP enabled at aap-core so please feel free to shoot your questions, if any.

Existing ports

This repository used to contain a handful of sample projects, but to avoid bloat core library repository, they are split from here and have their own repositories. Now they are listed at AAP Wiki.

aap-juce-plugin-host can enumerate the installed AAP plugins on the system (not limited to aap-juce ones), and instantiate each plugin.

At this state, this repository itself is almost only about a set of build scripts that lets you port your (or others') JUCE audio plugins and hosts to AAP world. And probably more importantly, this README.

Why JUCE for AAP?

JUCE is a popular cross-platform, cross-plugin-format audio development framework. JUCE itself does not support AAP, but it can be extended by additional modules. JUCE also supports Android (you can even run UI), which makes things closer to actual app production. Still, JUCE is not designed to be extensible enough, additional code to support AAP is needed in each app.

While JUCE itself is useful to develop plugin formats like AAP, it is designed to be independent of any other audio development toolkits and frameworks. We stick to minimum dependencies, at least on the public API surface.

JUCE API is stable-ish, while AAP API is not. So if anyone wants to get audio plugins portable without fear of API breakage, JUCE can be your good friend.

Note that JUCE plugins are usually designed for desktop and not meant to be usable on mobiles. In particular -

  • their UIs are usually useless on mobile.
  • those plugins that lets user pick up local files would not fit well with Android paradigm.
  • Some plugins would expose performance issues too.

How to try it out?

You would have to build and install each host and/or plugin from source so far, or look for the APKs from the build artifacts zip archives from successful GitHub Actions workflow runs. They could be installed via AAP APK Installer.

You need a host app and a plugin to try at least one plugin via one host. This repository does not contain any application within itself.

The host can be either aaphostsample in aap-core repo, a project aap-juce-simple-host that is somewhat tailored for AAP and mobile UI, or AudioPluginHost in aap-juce-plugin-host repo (which is JUCE AudioPluginHost with AAP support).

The plugin can be either aapbarebonepluginsample in aap-core repo (more stable), or any plugin on the AAP Wiki.

For those aap-juce-* repositories, make will build them.

For JUCE apps that use Projucer, JUCE Android apps are generated and built under Builds/Android/app/build/outputs/ in each app directory. Though we typically use Android Studio and open Builds/Android and then run or debug there, once top-level make ran successfully.

For those projects that use CMake, it is app/build/outputs.

App Build Instruction

CI builds

aap-juce itself is a set of JUCE modules that itself does not "build". But still, there are reusable GitHub Actions workflows under .github directory: one for CMake based projects and another for Projucer based projects. They are kind of normative build instructions (in that it is offered by ourselves).

The actual build is one make call if all conditions are met. In other words, every project that uses the workflow is adjusted to build with that.

As long as other project follows the same structure, you can reuse it too. It is safe to use the versioned workflow by commit rev. as we will be making breaking changes.

Building locally

As a prerequisite, you need Android SDK. If you install it via Android Studio it is usually placed under ~/Android/Sdk on Linux, and ~/Library/Android/sdk on MacOS. You also need Android NDK, most likely at least r23 (our latest development version uses newer ones).

For those project that use Projucer: depending on the NDK setup you might also have to rewrite Makefile and Builds/Android/local.properties to point to the right NDK location. Then run cd Builds/Android && ./gradlew build instead of ./projuce-app.sh. It would be much easier to place Android SDK and NDK to the standard location though. Symbolic links would suffice.

CMake based projects would similarly need to tweak Makefile, but other than that it is a typical Android Studio (Android Gradle) project.

Additional notes on Projucer

aap-juce basically recommends CMake for porting JUCE plugins to Android, but it is still technically possible to use Projucer-based projects for porting.

Since Projucer support needs quite a lot of more documentation, we have consolidated Projucer-related topics to docs/PROJUCER.md to keep this document cleaner.

Porting a plugin or a host to AAP

To port existing plugins, or even with a new project, you will either follow the CMake way, or the Projucer way. You would normally have no choice, the original project would be either of those already, but CMake is much easier and much more intuitive to deal with. With Projucer, you will have to generate project every time you make changes to the project. In either approach, you end up with an Android Studio (Gradle) project that you can open on Android Studio (or stick to Gradle to build and adb to install, like we do on CI).

There are many aap-juce based apps that could be used as reference/template projects. See the list of plugins on the AAP Wiki.

Making application itself build for Android

If you are trying to port an existing project to Android, the first thing to do is to make it build for Android, regardless of AAP. If it is a Projucer project, open Projucer, add Android Studio exporter, resave, open on Android Studio and try to build. If it is a CMake project, check the next section ("Make AAP-specific changes: CMake").

JUCE API is in general less featureful on Android than desktop. For example, you have no access to synchronous dialog boxes. So you will have to rewrite code to follow asynchronous way or disable code so far. Once it's done, let's mark it as the porting target application. (They were deprecated in recent JUCE versions in 2021, so newer projects would suffer less.)

Make AAP-specific changes: CMake

For a project that build with CMake, it is fairly easier to port to AAP.

There are existing sample projects listed earlier on our AAP wiki page, and to port an existing plugin project (or even if you are going to create a new JUCE plugin project), it is easier to create new project based off of those existing ones, making changes to your plugin specifics. For details, see docs/PLUGIN_PORTING_GUIDE.md.

There are some important bits:

  • JUCE needs some changes. JUCE-support-Android-CMake.patch is applied if you build those ports with make.
  • The plugin's top level CMakeLists.txt : we need Standalone plugin build (as no other formats are supported, and on Android it is built as a shared library). We also (typically) patch this file to add build setup for AAP specifics.
  • app/src/main/cpp: is typically a symbolic link to the JUCE plugin app source (e.g. cpp -> ../../../external/dexed).

A typical porting trouble we encounter is that even if the activity launches, it shows an empty screen. It is because the application somehow fails to bootstrap (call to com.rmsl.juce.Java.initialiseJUCE()).

Another typical problem is that it fails to load the plugin shared library. It is due to missing shared library within the apk, inconsistent aap_metadata.xml description (either library or entrypoint attribute), or missing entrypoint function symbol in the shared library (which must not be visibility=hidden).

Creating aap_metadata.xml

Starting aap-core 0.7.7 along with its parameters extension v2.1, it supports dynamic parameter population by code, and aap-juce fully makes use of it. This feature makes aap_metadata.xml simply editable by human beings i.e. you can just copy existing aap_metadata.xml from other project and replace "names" in it.

It used to be "generated automatically". The next section explained that, but it is totally passable anymore.

Generating and updating aap_metadata.xml

NOTE: this only applies to aap-juce 0.4.8 or earlier. The generator is not part of the build anymore. You can however still try to build and use it by making changes to aap-juce codebase. The build tasks in the old Makefile.common and generate-metadata.sh would be helpful.

This only applies to plugins (hosts do not need it).

aap_metadata.xml has to be created for the plugin.

Starting aap-juce 0.4.7, we do not really have to "generate" it automatically - we could just copy some aap_metadata.xml and modify it to match your project (especially, names and the native library filename). Therefore, we deprecate the following paragraphs.

There is some non-trivial task: `aap_metadata.xml` has to be created for the plugin. Sometimes it can be hundreds of lines of markup, so you would like to automatically generate from existing code. There is `update-aap-metadata` target in `Makefile.common` or `update-aap-metadata-cmake` target in `Makefile.cmake-common`, but in case you would like to run it manually... To import JUCE audio plugins into AAP world, we have to create plugin descriptor (`aap_metadata.xml`). We have a supplemental tool source to help generating it automatically from JUCE plugin binary (shared code).

Dealing with different JUCE versions

JUCE sometimes involves incompatible changes between versions, and sometimes they involve those project file generators. We have some Makefile variables that changes the behavior. It is worth inspecting Makefile.common for Projucer-based project and Makefile.cmake-common for CMake-based projects (they are often added).

Under the hood

JUCE itself already supports JUCE apps running on Android and there is still no need to make any changes to the upstream JUCE, unless you want to build CMake based project (see this post by @atsushieno for details).

On the other hand, we make a lot of changes to whatever Projucer generates. Projucer is not capable of supporting arbitrary plugin format and it's quite counter-intuitive to try to use various option fields on Projucer. Thus we simply replace various parts of the generated Android Gradle project. It is mostly taken care by projuce-app.sh.

CMake is preferred, but it is not officially supported by JUCE so far either. However the impact of the changes is small so that they can be manually fixed.

We plan to juce_emscripten for future integration with wasm UI builds.

difference between normal JUCE Android app and JUCE-AAP Android app

We have a lot of works for Projucer-based projects here, but things are much simpler for CMake support. We simply use our own app template with slight changes and reference to CMakeLists.txt from the app that is being ported.

GUI limitation

aap-core since 0.7.7 provides preliminary native plugin-process GUI functionality, but since JUCE GUI does not work as a standalone View, unlike Jetpack Compose,or Flutter, it is impossible to reuse existing desktop UI at the moment. JUCE plugins even invalidates whatever Activity we specify at AndroidManifest.xml and launches its own JuceActivity instead. It is a brutal behavior, but we cannot fix without a various patching effort.

At the moment, you are encouraged to build a dedicated mobile UI for JUCE based plugins, without juce_gui_basics. Or push JUCE team to improve their GUI support to make it just work as View.

Using AddressSanitizer on aap-juce apps

It is tricky to set up ASAN for aap-juce apps, especially for those projects that use Projucer (as it regenerates the projects every time you re-save .jucer).

The easiest way would be to copy setup-asan-for-debugging.sh to (app)/Builds/Android/ directory, modify the script to have ALL_APPS variable to point to app directory, and run it there. For CMake-based projects, it can be just the top directory (and point to the source as well).

Then you have to make some changes to the build scripts (build.gradle(.kts) and CMakeLists.txt) to take those options. You can track how enable_asan variable in aap-core repository is used.

There is one more change needed: Projucer generates CMake arguments to contain -DANDROID_STL_c++_static. It has to be changed to -DANDROID_STL=c++_shared.

Note that if you are on Projucer based project, Projucer will clean up all your efforts every time it resaves the project.

Profiling

Both aap_audio_plugin_client and aap_audio_processors implement profiling support using ATrace API, just like aap-core and aap-lv2 do. The profiling is done at both including and excluding aap-juce specific parts.

For more details on AAP tracing, read the aap-core documentation (it is a permalink; there may be updated docs).

Code origin and license

This repository itself is licensed under the GPLv3 license.

aap-juce's People

Contributors

atsushieno avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

Forkers

whowant-ui

aap-juce's Issues

Unify build scripts

One of the reasons why we created this repo is to ease unifying multiple projects, and makes it easy to enable Oboe in JUCE for Android builds.

Create a commonized build task to copy files resources as assets and add initialization provider to extract them at first run

While creating aap-juce-audible-planets port, I noticed that there would be common build task to copy some local contents as assets to extract under app-specific file at the initial run time. AudiblePlanets requires its presets repo contents copied into certain local data directory.

aap-lv2-sfizz does first-run setup for sfz too. We should provide some common build targets to achieve that.

AudioProcessorEditor integration

We used to plan the GUI support as Web UI (#22). As of AAP 0.8.0, we have in-process plugin UI support, so we do not necessarily have to take that approach anymore. If we could reuse AudioProcessorEditor within the native UI context, that would be probably easier.

Having said that, JUCE on Android does not provide a way to show plugin UI. It only supports Standalone apps, and that means it expects its own JuceActivity. We need much "less integrated" JUCE UI, ideally running just as an android.view.View.

get practical music sequencer (player) using tracktion_engine

(inherited from atsushieno/aap-core#11)

tracktion_engine builds on Android, and it is most likely that it can handle audio plugin related bits in JUCE. Since we have juceaap_audio_processor, technically tracktion_engine should be already usable for AAP.

augene project can be used as a reference music player. It is very simple auduo plugin based music player based on tracktion_engine.

Problem: even if we get this working, there is no "instrumental" sample yet.

switch to CMake-based build.

former issue: #1

Now that we have migrated to juce6, it is looking possible to switch to CMake-based build solution, which is likely better than dealing with Projucer.

There is actually a couple of minor concerns:

  • CMake requirements: it requires CMake 3.15, which means we need additional download steps on CI servers as well as local.properties hack to add CMake directory settings.
  • JUCE's CMake support is not like, Projucer can generate a natural CMakeLists.txt outcome. It has to be manually written.

On a side note, the Android Studio issue on taking infinite time on indexing is actually irrelevant to Projucer oldness. It will happen even with modern CMake-based solution.

Since the enhancement is not really big, we'd leave it as an enhancement issue.

No audio outputs from some synths

SARAH and Magical8bitPlug2 generate no sound, while andes and mda EPiano does generate valid output. Tested on AudioPluginHost and aaphostsample.

strip out "aap-metadata-generator" part from ordinary build process.

We run aap-metadata-generator to generate aap_metadata.xml from AudioProcessor implementation class. To achieve that, we first build Linux or Darwin version of the plugin, then link it to the extractor console tool.

That takes long time before starting the actual Android project build, while it is only to generate the metadata. And the metadata is actually unchanged unless code changes happen. It is good to run the metadata generator whenever code update occurs, but it actually rarely happens.

Thus, it is probably better to split out metadata generation task from the ordinary builds.

batch updates to all subprojects

This in general applies to the following components, this time:

  • aap-juce to the latest
  • AAP to 0.6.20
  • JUCE to 6.1.2
  • AGP to 7.2.0-alpha04 (along with gradle 7.3-rc-1)

Progress:

  • aap-juce-plugin-host
  • aap-juce-helio
  • aap-juce-obxd
  • aap-juce-dexed
  • aap-juce-odin2
  • aap-juce-hera
  • aap-juce-ports
  • aap-juce-frequalizer -> still not usable due to atsushieno/aap-juce-witte-eq#4 (common JUCE effect plugin issue)
  • aap-juce-witte-eq
  • aap-juce-chow-phaser -> still not usable (ditto, but the problem surface looks different)
  • aap-juce-augene -> skip it, too old

Faster preset scanning

Currently our aap-juce presets scanning involves loading of entire preset data to just get its name. Preset scanning does not happen often, but it takes too long time on some plugins. The newest example now is aap-juce-byod - it involves heavy-weight ML operations where each of the preset takes seconds to load. It is not really desirable.

Android Studio goes "indexing..." at `/home` directory which takes infinite time and prevents any further operation

It took like an entire night to finish indexing at "/home" (which actually is ~/, not /home) which is stupid. The problem is that unless AS finishes that "indexing" step, it does not load device list and no further exec/debug operation cannot be performed.

AAP itself has no problem. Projucer-generated default GUI App has no problem either. Something between them and this is causing the issue.

image

Simplify CMake scripting changes

It would be nice if we can just make only a few lines of changes to the existing CMakeLists.txt.

For example, clap-juce-extensions makes it to build CLAP version (from its README):

add_subdirectory(libs/clap-juce-extensions EXCLUDE_FROM_ALL) 
clap_juce_extensions_plugin(TARGET my-target
        CLAP_ID "com.my-cool-plugs.my-target"
        CLAP_FEATURES instrument "virtual analog" gritty basses leads pads)

We could probably do the same.

CMake-ify `make generate-aap-metadata(-cmake)` target (or overall Makefile targets)

Currently if the target plugin product name contains a whitespace (e.g. "Surge XT", or "DDSP Effect") metadata generator fails to handle it. It is because our hack is ugly and resort to some builder shell script (generate-metadata.sh). It has to be cross-platform across Unix-y platforms and that brings in headache.

It should not happen if we simply migrate to full CMake world.

repository split

After the successful aap-lv2 repository split, this comes next.

rationale

We should make aap-juce module widely usable, not just by forking and/or adding more projects to this repo. This repo is getting fat and now it takes 3 hours to build. Each project takes 30~ minutes.

JUCE porting builds are almost identical in each project, but they are time consuming, and there are still minor glitches (such as OB-Xd renaming project files for Mac-only due to Xcode naming mismatch).

Also, there are CMake based projects nowadays, which is not compatible with jucer-based solution (such as Tracktion Engine). I'm in the other process making CMake support working in standard Android Studio project which incorporates CMake, not by hacky and immature project structure generated by Projucer.

Migration steps

The first step is to split out samples from this repo. It is being done at aap-juce-ports repo, which so far contains whatever this repo should still provide (modules, tools, etc.) as hack, and existing sample project support files (Makefile and patches).

Once it goes green, we remove references to those samples from this repo. Maybe even AudioPluginHost: it is essential, but it takes 30-ish minutes to build it, which is extraneous for plugin projects that will submodule this repo.

Then I can look to CMake migration and possible build time optimization. Maybe after further repository split (to ease CI build caching).

design ideal module source structure for app/plugin developers

The current state of aap-juce support is a big hack and not practically ready for external developers. We have to restructure the entire repo to ease porting.

  • JUCE-AAP modules: copy AAP header files directly under the module sources so that any subsequent huge checkout becomes unnecessary.
  • distribute androidaudioplugin.aar and prebuilt native dependencies via Maven so that at least they can be simply added as a Maven dependencies, along with those header files above. (It is rather an issue in android-audio-plugin-framework.)

Emscripten support is another issue that needs a lot more effort, so it can be skipped for now.

support dynamic port changes in AAP-JUCE (and AAP itself)

From #10 (comment):

Now Dexed crashes here:

9935-9958/com.digitalsuburban.dexed I/JUCE: JUCE Assertion failure in juce_AudioSampleBuffer.h:275

(snip)

It is most likely related to atsushieno/aap-core#44 i.e. inconsistency between list of "defined" ports vs. the actual JUCE channels. While supporting dynamic ports with static known ports is doable, it must be properly distinguished at implementation.

Rename modules

I have no idea why, but those juceaap modules have flipped module names. I thought I fixed them once, but apparently not.

To avoid confusion, we would rename those modules to the following:

  • juceaap_audio_processors => aap_audio_plugin_client
  • juceaap_audio_plugin_client => aap_audio_processors

This will involve a lot of changes everywhere in aap-juce-xxx repos.

Eliminate JavaVM->AttachCurrentThread() from JuceAAPWrapper

In this code, it tries to let JavaVM attach to current thread.

https://github.com/atsushieno/aap-juce/blob/main/modules/juceaap_audio_plugin_client/juceaap_AAPWrappers.h#L41

But this constructor is actually called by the plugin service binder, which means the caller can be an audio thread.

Although if we simply remove this #if ANDROID part, the exception below happens:

java.lang.RuntimeException: Can't create handler inside thread Thread[Binder:5724_4,5,main] that has not called Looper.prepare()
        at void android.os.Handler.<init>(android.os.Handler$Callback, boolean) (Handler.java:227)
        at void android.os.Handler.<init>() (Handler.java:129)

The code sometimes causes run-time crash for unknown reason.

We will have to determine what to do here.

web-based UI integration

context: atsushieno/aap-core#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.

hosting: freezes at instantiating a plugin

both aap-juce-plugin-host and aap-juce-helio seems to freeze when it tries to instantiate a plugin. It was not like that a few months ago, so it must be fairly recent regression.

Some JUCE effect plugins do not reflect parameter changes

It seems aap-juce-simple-reverb does not seem to receive parameter changes on aaphostsample (and probably AudioPluginHost, cannot verify it as it's too unstable and always crashes before I connect some instrument and SimpleReverb, play some notes, change parameters and play some notes again).

Migrate to JUCE6 and convert .jucer to CMakeLists.txt

Things have been improved from "build manually copied sources with modification" to "copy from submodule, apply tiny patch, alter .jucer and build" now. As a next step, if the .jucer files can be automatically converted from original sources, that would be great.

Most of the changes are already described on README.md, and it wouldn't be too hard to create some sort of converter script that manipulates the .jucer XML files.

Support building multiple plugins

Currently there are couple of plugins that builds multiple plugin artifacts (and that I am aware of):

  • ChowPhaser (Mono/Stereo)
  • ADLplug-AE (ADL/OPN)
  • DDSP-VST (Effect/Synth)

So far aap-juce build system only brings in one plugin, but that is not ideal. We should be able to build and package multiple plugins within an apk.

JUCE issue: JUCE apps opens MIDI devices at startup

It is super annoying, but when we launch aap-juce-simple-host and aap-juce-plugin-host, it tries to access ALL midi devices including MidiDeviceServices and actually opens some MIDI devices. It does not make sense. It tries to open my fluidsynth-midi-service-j which is MIDI OUTPUT device. It happens due to the infamous JUCE on Android bug that it mis-recognizes MIDI output devices as MIDI input devices.

That feature should be completely scrapped within JUCE itself. Therefore we will need another patch to fix it.

The same goes for JUCE plugins because we use Standalone apps, but fortunately there is #if JUCE_DONT_AUTO_OPEN_MIDI_DEVICES_ON_MOBILE conditional check in the JUCE sources, so we could individually apply that. We already disabled that auto open garbage in projuce-app.sh so projucer-based apps won't open it. We still have to apply this individually in CMake based projects though.

Implement dynamic parameter list generation at runtime and deprecate aap-metadata-generator

Currently we kinda have to run AAP metadata generator because otherwise it is annoying to write everything manually. But nowadays AAP supports dynamic parameter lists at runtime, so it would make more sense to avoid static parameter list. They do not really contribute to plugin listup anyways.

It will practically result in eliminating need for the metadata generator, which has been PITA.

Find the right way to make plugins debuggable

The biggest issue on diagnosing issues in JUCE based plugins is that it is impossible to debug with Android Studio for some reason. Some reason actually is, debugging plugin requires apps kept alive while debugging the service part but it is somehow not possible.

(1) Usually when I debug LV2-based plugins, I launch standalone app activity, then go back to home screen (or app list) to launch a host to connect to the plugin service. The service is still alive and I can simply add android.os.Debug.waitForDebugger() in MainActivity with no problem.
(2) But the Main Activity (JuceActivity) from JUCE-based plugin apps, if I go back to home screen or app list, it terminates the application and debugger stops. Even after I modify app AndroidManifest.xml and make the Activity launchMode='standard'.
(3) If I create another launch configuration that does not launch main-launcher Activity and add android.os.Debug.waitForDebugger() at JuceApp.onCreate(), the debugger still often does not break and I have no idea why.

It may depend on call to Java.initialiseJUCE (this) in JuceApp but we need some solid debugging experience.

get Helio Workstation working to some stage

apart from #6 I wanted to have a working DAW, which is like an ultimate goal towards 1.0 release.

Helio is based on JUCE, and it supports Android, so I ended up to add AAP support on it and created a repo as aap-juce-helio. At this state, helio can list up AAPs, and it seems able to instantiate them. Though it is still not "working", especially in that:

  • the plugin listing is weird. It is rather a helio issue (text too big, without wrapping)
  • no audio output port is recognized, so it is simply impossible to connect to audio out and emit any sound.

I would visit this issue on occasion.

regression: some MIDI synths do not generate valid audio output on hosts

While JUCE AudioPluginHost generates some audio outputs for Andes, it only generates noises on OBXd and Magical8bitPlug2. And no synth generates valid sound on aaphostsample.

Since MDA pianos generate valid outputs on both hosts it is specific to JUCE based instruments. Weird is that Andes still generates audible sound on aaphostsample...

It is confirmed on juce6 branch.

JUCE issue: cannot replace MainLauncher to aap-core PluginListActivity

Currently, aap-juce plugin ports launch JuceActivity, which is the main entrypoint of the app. But they are in general useless because they are designed to run as a plugin UI (we are seeing Standalone build of the app). It is not what we intend to show.

What we should do instead is to show the "plugin settings and playground UI" aka. PluginListActivity in androidaudioplugin-ui-compose. Then it can present "Show UI" command to switch to it (or show overlay Window if possible).

Bonus if it can control the plugin instance in use (but needs connection management).

Vital

It has some difficulty. It's project .jucer files are scattered around, and neither plugin nor standalone even builds without tricky tweaks. JUCE modules are embedded, without Projucer, and we're not sure if they contain any changes to the original. And now I have an Android app project that builds, which does not show anything (due to missing juce_CreateApplication()).

automate Emscripten builds

As part of UI integration scenario, wasm builds are part of the big picture in AAP to support in-process editor UI. atsushieno/aap-core#34

We need those builds automated within this repo. A big issue here is however, Emscripten builds are not fully generatable via Projucer yet. We either commit Builds/Emscripten, or enhance Projucer to add support for juce_emscripten (which I kind of avoid, because it's going to make merging upstream harder).

some plugins crash at startup

List of plugins that are known to crash at startup. They might be due to the same reason.

  • dexed
  • SARAH
  • Magical8bitPlug2

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.