Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flutter framework collision when embedding in a VST or AudioUnit DAW plugin #104144

Open
hbursk opened this issue May 19, 2022 · 7 comments
Open
Labels
a: desktop Running on desktop c: proposal A detailed proposal for a change to Flutter framework flutter/packages/flutter repository. See also f: labels. P3 Issues that are less important to the Flutter project platform-mac Building on or for macOS specifically platform-windows Building on or for Windows specifically team-desktop Owned by Desktop platforms team triaged-desktop Triaged by Desktop platforms team

Comments

@hbursk
Copy link

hbursk commented May 19, 2022

Use case

I'm exploring using Flutter in a DAW plugin, VST and AudioUnit. A Host like Ableton Live running a plugin is a different environment than a standalone desktop application. In this context, two plugins both using Flutter collide. The first App.framework to be linked is the one that plugin instance will load. This means that loading Plugin B, will actually launch the flutter application for Plugin A.

I'm currently using JUCE, which is a convenient way to build a plugin. The JUCE window creates an NSView, and I add the FlutterViewController to it, embedding the App.framework and the FlutterMacOS.framework into the plugin bundle. I've attached an example with two flutter Hello Word apps embedded into a JUCE plugin. One uses the standard blue theme while the other uses red.

Example Videos

Two plugins colliding:

TwoPluginsCollide.mov

One red plugin loads correctly:

OnePluginIsCorrect.mov

Example Source Code

JUCE/Flutter example projects with included README:

https://www.dropbox.com/s/juib7oqnsyzu2qd/FlutterDAWPluginExample.zip?dl=0

Proposal

I believe the above issue could be resolved if we could optionally add a naming prefix to all of the generated frameworks including plugin packages.

App.framework and FlutterMacOS.framework would become MySpecialNameApp.framework and MySpecialNameFlutterMacOS.framework. Flutter would have to be told to link these frameworks instead.

Not just the framework packages would have to be renamed, but all the files needed to keep the symbols from colliding.

If we only do this for App.framework to solve the described issue, there would still be collisions with mismatched versions of the FlutterMacOS.framework as well as commonly used flutter plugin packages. That's why I believe it should be done for all the embedded frameworks.

I'm very open to alternative solutions that may solve this issue.

Thank you for your consideration,
Hayden Bursk

@darshankawar darshankawar added the in triage Presently being triaged by the triage team label May 19, 2022
@darshankawar
Copy link
Member

@hbursk
Thanks for the report. If I understand correctly, you are looking for a way to embed (ex: VST or AudioUnit plugin) in Flutter framework specially for macOS. If yes, can you check if this issue resembles your case ? #80339

@darshankawar darshankawar added the waiting for customer response The Flutter team cannot make further progress on this issue until the original reporter responds label May 19, 2022
@hbursk
Copy link
Author

hbursk commented May 19, 2022

@darshankawar Thanks for your response. I have manually embedded the Flutter frameworks as mentioned in that thread successfully. The issue that I describe is unique to a DAW plugin where Flutter frameworks with the same name collide.

While my example is for macOS, I would need this feature for Windows as well since a similar issue would occur with the DLLs.

So I’m not looking for add to app functionality like iOS or Android. I’m looking for a way to give the generated frameworks more unique names to avoid collision and for the Flutter engine to be able to consume those uniquely named frameworks.

@github-actions github-actions bot removed the waiting for customer response The Flutter team cannot make further progress on this issue until the original reporter responds label May 19, 2022
@darshankawar
Copy link
Member

Thanks for the feedback. Keeping this issue open and labeling for further insights from the team.

@darshankawar darshankawar added platform-mac Building on or for macOS specifically platform-windows Building on or for Windows specifically c: proposal A detailed proposal for a change to Flutter a: desktop Running on desktop framework flutter/packages/flutter repository. See also f: labels. p: third party and removed in triage Presently being triaged by the triage team labels May 20, 2022
@gspencergoog gspencergoog added the P3 Issues that are less important to the Flutter project label May 26, 2022
@awood314
Copy link

awood314 commented Jun 8, 2022

I have been working with these examples with JUCE and Ableton Live. It does seem that the frameworks are overwriting each other, but I'm not sure if the naming is the issue.

For simplicity, I will refer to a DAW plugin as a "VST".

When running a VST in a DAW, the DAW is the host bundle and process, so I'm guessing that this might not retrieve the appropriate dart bundle.

I was able to partly solve this issue by using explicit paths to refer to the App.framework dart bundle when initializing the FlutterViewController using initWithProject (see flutter_juce.zip which contains two similar demo projects)

Screen Shot 2022-06-07 at 5 15 10 PM

However, this only works when integrating the debug artifacts from the flutter build, and not when using the release artifacts. After reading this wiki about AOT mode, my theory is that this is due to the fact that both VSTs share the same dart VM (since there is only 1 per process and they are both running in the same DAW host process). After loading a VST built with the release artifacts (AOT), any other VST loaded will show that same project in their window, as Hayden initially described, presumably because the shared VM is initialized to only run that project. On the other hand, when first loading a VST built with the debug artifacts (JIT), then other "JIT" VSTs can be loaded and show their corresponding project, but loading any "AOT" VSTs at this point shows no flutter view at all.

A complete solution to this would mean that we could create a flutter-VST that can be "isolated" from other flutter-VST projects running in the same process. I'm still trying to wrap my head around the flutter engine architecture (dart VM, embedder, shell, etc.), so any advice would be much appreciated. My next step is to understand if this is fundamentally divergent from the flutter architecture principles or if there may be at least a workaround solution.

I understand that a minimal reproducible example that doesn't depend on JUCE and DAWs would be helpful, but I'm not entirely sure yet what that would entail. I imagine maybe building the "plugin" projects as separate dynamic libraries that get linked into a "host" app might be sufficient, but I worry it might not cover all the intricacies of DAW plugin hosting.

@awood314
Copy link

awood314 commented Jun 9, 2022

I found a workaround to fully resolve the collision issue.

In the shell/VM initialization, I inserted an explicit path to App.framework/App to Settings::application_library_path. This way, when the Dart VM is started, it does not resolve the VM snapshot from the current running process (which would be the host DAW), but instead uses that path to directly create a mapping

With this change, the VST built with this custom engine was essentially isolated from the other VST, and could run its own flutter app regardless of what order the VSTs were loaded in.

I'm not sure yet how to flesh this out into a reasonable PR, since I don't know fully what the implications are, or if there is other work in progress in this area. I noticed that the ios implementation of FlutterDartProject has something similar, plus a lot of other Settings configuration, while the macos version has none.

It may be also worth noting that it seems that this problem does not occur with a Windows implementation

@awood314
Copy link

Just discovered these issues which describe the crux of the issue with this use case:

#43351
#43454

@MelbourneDeveloper
Copy link

Hi @hbursk

Did you ever have any success with Flutter VSTs? I would really like to explore what's possible with Dart and Flutter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a: desktop Running on desktop c: proposal A detailed proposal for a change to Flutter framework flutter/packages/flutter repository. See also f: labels. P3 Issues that are less important to the Flutter project platform-mac Building on or for macOS specifically platform-windows Building on or for Windows specifically team-desktop Owned by Desktop platforms team triaged-desktop Triaged by Desktop platforms team
Projects
None yet
Development

No branches or pull requests

7 participants