-
Notifications
You must be signed in to change notification settings - Fork 26.7k
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
Comments
@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. |
Thanks for the feedback. Keeping this issue open and labeling for further insights from the team. |
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 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. |
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 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 It may be also worth noting that it seems that this problem does not occur with a Windows implementation |
Hi @hbursk Did you ever have any success with Flutter VSTs? I would really like to explore what's possible with Dart and Flutter. |
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
The text was updated successfully, but these errors were encountered: