You mean using a Windows host in wine, the topic is about plugins bridged to Linux hosts (using wine/yabridge).
1 Like
Oh, wellā¦ Owning several hundred plugins literally, I can tell you with a clean conscience that a native Linux plugin IS a solution. I use Wine only because I canāt do otherwise. And this causes me many troubles, so that Iāve abandoned many of them. Iāve bought them, so itās a nice thing for the vendor, but I will not renew or buy others from the same vendor. And from now on, seen the troubles JUCE 8 is causing, I double-think before buying other non-native plugins. And most of the time I decide not to. I know that we Linux users are second-class citizens, but itās a chicken-egg story.
And we have a great community, so if a vendor declares that their Linux native build is beta-quality or have not the same quality of support, we can deal with that. Anyway, again, I know weāre still a minority.
Cheers and much love,
Fabrizio
2 Likes
My comment was about Linux WINE users who use Windows DAWs and run the plugins there. They canāt use native Linux plugins. I didnāt notice that this thread is only about bridged plugins in Linux hosts. @drmr-2 corrected me. But both groups are affected by this problem.
1 Like
Iām not sure I understand what you mean. Just adding a small patch for us wine users to fall back to software rendering is arguably not āpartial supportā, just throwing us a bone. Like, if the fallback renderer does not work I donāt think (or at the very least I strongly hope so) that the Linux community would blame you for not supporting Linux especially since you already went out of your way to help us out.
I would assume that there is a tacit, implicit understanding that when you use wine - you expect that some things will break and not work as expected and itās not the developers fault. But when a developer goes out of their way - even a little bit - to meet the Linux community in the middle and adjust their stuff a little bit, they win a lot of goodwill. Every Linux music producer that Iāve met just raves about the u-he stuff 
If I undetstand the maintainer Tom correctly, a simple patch wonāt make it consistently compatible with WINE.
If you do want a Linux version, the best option might be asking the developer to release a Linux native version.
One exception is for users who also run their DAWs in WINE (@kunz have mentioned that). I have received one request for this, but most Linux users are satisfied with the Linux native version.
1 Like
Yeah, and I just was arguing that a small patch that increases compatibility is better than nothing - unless the community becomes toxic over expecting it to work. Then Tomās position is entirely justified and understandable.
Itās a small patch. It needs to detect wine (thereās already a function in JUCE to do that) and then fall back to the software renderer. Additionally, the very outdated fonts that JUCE uses for wine (using that very detection function) should be exchanged to fonts present on modern linux systems.
I donāt get why developers donāt just patch their own JUCE forks. This can be done with minimal changes and then linux users are generally savvy enough to get things to run.
4 Likes
The āmostly workingā is my concern. A small patch within JUCE itself would imply that itās completely supported, like all of our other targets/platforms.
A more robust position would be to remove all mentions of Wine from JUCE and explicitly list it as an unsupported target.
Perhaps a preprocessor variable named along the lines of JUCE_SUPER_HACKY_UNMAINTAINED_WINE_SUPPORT would be the best compromise.
2 Likes
I agree that removing all wine parts in the code (itās just a few) would be a step forward. Right now, the thing with the font names is basically sabotage.
Maintaining your changes in a fork is work and an additional risk. It does not matter if the change is small. Imagine the JUCE team now removes all the WINE workarounds/hacks.
If you look at the recent survey, youāll find that most pro users maintain their own forks.
With the initial troubles after the JUCE 8 release, it felt almost impossible not to have a fork with some fixes. IMHO it was more risky not to have a fork.
GitHub makes it very easy.
IMO temporary emergency fixes for a few weeks or even days and features you have to maintain forever are a different thing. I look at WINE support as something the JUCE team should decide.
1 Like
is there any news on this front? itās increasingly frustrating to download a plugin to just be greeted with a black plugin window. I donāt assume that all of them are juce 8 plugins, but juce is pretty popular.
I would gladly implement direct2d 1.3 in wine myself if I could, but that requires experience that I just donāt have.
in the environment where windows is pumped full of AI slop bugs and bloat, and linux is pretty useable for most people (the question of them actually using Linux notwithstanding) itās pretty disappointing to run into this regression on the linux side.
Iām not qualified to do this implementation in Wine myself, but I think what I can contribute is a minimal example, with source code, to help Wine devs. Iām looking to learn enough JUCE to make this possible.
The communityās workarounds tend to involve trying to force software/OpenGL rendering, so a minimal example that reproduces this behavior should not force or fallback to software rendering. If Iām creating a Hello World JUCE8 application, would I have to do anything specific to use Direct2D or will this happen by default?
1 Like
We have added automatic fallback to software rendering when we detect Wine:
This is absolutely not āJUCE apps/plug-ins now support running under Wineā, but I hope we can reduce the number of JUCE forks being used by people.
15 Likes