-
Notifications
You must be signed in to change notification settings - Fork 2
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
Discussion regarding the runtime and approach #5
Comments
Why isn't the version of org.freedesktop.LinuxAudio.Plugins implied by the package runtime version? |
I have a few questions... as I have hit a brick wall how does one point a DAW that is in one container to a plugin that is in another container? where is the link? because it's not possible to navigate to that location... it's as if Host and Plugin are on different VM or Emulations... What would be the mechanism to bridge from Host to Plugin with Flatpak? currently if I open Bitwig it can only read plugins that our outside the Flatpak ecosystem and only if they are in the |
No. Flatpak app don't have access to anything installed as part of the OS (think /usr /opt or whatever else).
Yes. Apps can have access to the $HOME directory. It is the default for most app that support audio plugins. See
Any Linux audio plugins packaged for the same runtime version. Right now all are on 20.08. I made sure to transition quickly from 19.08 when the transition happened.
They are ignored, ie Flatpak will not load them with the app. The extension point is versioned.
There are issues that needs work.
The runtime is the runtime from the app anyway. I can see if maybe we can have a unversionned extension point in parallel.
No. This is solely for flatpak. |
Each app is in its own sandbox. The extension installed are automatically "mounted" following the extension point. For bitwig it is defined as:
A plugin is installed in the sandbox in
None. Except for what is
There is an issue with Bitwig is that the search path need to be set (I tested that, it still works) As for the argument that For example |
BTW I have a manifest for Podolski if you want to give it a try :-) |
it's still not clear to me as the Bitwig container is here
and Surge VST3 is here
how does Bitwig locate and subsequently load the Surge VST3? |
You instruct Bitwig to look for ST3 in flatpak does the rest. (think of mounting the extension filesystem in the right place in the bitwig Flatpak sandbox) |
yes thanks!!! |
Sure thing :-) |
Thank you very much! :) |
it's better to use you will notice duplicates otherwise |
I have a strong feeling that plugins using an older runtime could be mounted by an application using a newer runtime. That would work most of the time. |
You don't want to do that..
I can't get them to work since they insist on "installing" stuff in |
I also wonder about two things:
The plugin developer need a way to quickly iterate:
The daw developer needs to be able to debug his plugin host, but how does he load a plugin installed via flatpak into his daw being developed without a sandbox? Does he need to "deploy" to flatpak first? |
Maybe we need to start this discussion on the flatpak mailing list? |
Hi, I'm still very much interested in this discussion because the current situation sucks for both, maintainers and users. First, this makes it harder for maintainers because we have to maintain 2-3 branches of the exact same plugin(s). Feels like a waste of time and can lead to lacking motivation to backport stuff everytime. Would be great to have only one package/branch per plugin which works everywhere. It gets even worse if you consider the users perspective. It should be:
While it currently is:
Basically we expect everyone to be a technical person / power user. Sorry for the rant. This can be easly frustrating, also to me who knows how to deal with it. I see that there is something going on (or not? nothing happened since april)... at least there is an issue for flatpak: This is about flatpak automatically installing plugins from new branches. This doesn't fix:
So we cleary need to get rid if this branching if possible. But at this point I'm not sure yet. From my understanding it should be possible. Having only one branch per plugin, building all the plugins against an older SDK while using newer SDK for hosts/apps. Usually this works. Also this quote from @abique makes me even more confident about it:
This makes me pretty sure that plugin binaries built against the 20.08 SDK should work in 21.08 runtime. Then we could, in host apps like Ardour, mount plugins from multiple branches, which could look like this in the manifest:
or maybe, if we can't repurpose the version field (or completely ommit it?):
or something else but like this, which would make Ardour load all plugins built against 20.08 and 21.08 SDK. For now to me that looks like it could work. But at the same time I'm not sure. I guess there is a reason why @hfiguiere didn't choose to do it like this from the beginning which I currently fail to see/understand. I'm interested in an explanation in this case. |
Hi,
Thank you very much for your work on getting plugins into flatpak.
I'm a Bitwig Studio developer and I recently published Bitwig to Flathub.
I am also the maintainer of the linux port of u-he plugins, and I consider publishing those to flathub, but I'd like to clarify a few things first.
If I understand correctly, using Bitwig from flatpak will give me access to the plugins installed:
Is that correct?
What happens to plugins using an older runtime?
They may still work with a more recent runtime? It is forward compatible most of the time I suppose?
If the runtime needs to be the same for the plugin and the DAW then the transition to a newer runtime is tricky isn't it? It push additional problems for both the user and the developers making it a bad experience for the end user because he'd need to understand the runtime issue.
To me if we say that a plugin can target an old runtime and be used by a daw using a recent runtime, then it is a no brainer, the plugins needs to target the oldest possible runtime and the daw the most recent one. But I doubt that this approach will guarantee that the plugin will work.
Regarding u-he plugins, they are linked statically and only exports the vst2 and vst3 entry points. So they are safe from symbol clash during after dlopen(). And they don't depend on the flatpak runtime. So if there is a way to say "any runtime" or "no runtime"?
Can a plugin installed by flatpak be used by an app started on the system?
As a side note I wrote this a while ago: https://gist.github.com/abique/4c1b9b40f3413f0df1591d2a7c760db4 which is a different approach, but it would take years, had a mixed reception (so the idea is maybe wrong?) and might also never happen so I'm very happy if we have a good solution today.
Regards,
Alex
The text was updated successfully, but these errors were encountered: