Juce8 Direct2D WINE/yabridge

General JUCE discussion
73

You mean using a Windows host in wine, the topic is about plugins bridged to Linux hosts (using wine/yabridge).

1 Like
74

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
75

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
76

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 :grinning_face_with_smiling_eyes:

77

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
78

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.

79

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
80

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_MINGW_SUPPORT would be the best compromise.

2 Likes
81

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.

82

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.

83

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.

84

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.