First off, if I have to compile an unreleased version of something to get a proper implementation of a basic requirement for professional use, then it might as well not exist. no one with deadlines is going to go to those lengths and risk all the testing and instability caveats to get that.

Second, you have all sorts of plugin libraries based on their own spin of things. Gmic, script-fu, etc. — the ecosystem is the definition of fragmented in practical terms. if they do change things for the better, good, it’s just that they have a very, very long track record of ignoring or contravening user needs. if it works for your hobby stuff, great. More power to you. Anyone who trusts the GIMP core team to improve consistently has a decade plus of evidence against that notion staring them in the face, though. They’ve ruined any shreds of credibility they may have started with when they released their software all those years ago. I’m the first person who’d like to be proven wrong about GIMP, but I’ll need to see it in production to believe it.

Well, for starters, nondestructive editing workflows are a nightmare in GIMP, because the filter and layer subsystem code would need to be refactored to get them working in parallel. The color management was nonexistent for over a decade and what they added doesn’t work properly for print or digital proofing, and the entire effects stack is schizophrenic and split between different libraries, none of which work in real-time or in a nondestructive manner. GIMP also lacks proper interchange format support.

There’s been no less than 3 contentious forks of GIMP (the most current being glimpse) that were born from the maintainers’ inflexibility and refusal to change or improve various aspects of the software. Look through the issues and pull requests in their repos and mailing lists if you want specific examples.

As for the production audio stuff, I don’t bother any more. PA has terrible latency and buffer problems, jack is a huge pain to use, OSS is far too old for most software to explicitly support and pipewire and the other fringe alternatives are too new. there’s no commercial plugin support anyway, so you’re stuck with whatever your DAW comes with and any LV2 stuff you can scrape off github and compile successfully. Why punish yourself?

You know, I specifically started with questions rather than statements because I wanted to make sure we are on the same page. Well, nope, we aren’t. Not even close 🙂

Well, for starters, nondestructive editing workflows are a nightmare in GIMP, because the filter and layer subsystem code would need to be refactored to get them working in parallel… and the entire effects stack is schizophrenic and split between different libraries, none of which work in real-time or in a nondestructive manner

Not really. GIMP already has an API for attaching effects to layers. Its just bakes everything back into the drawable/buffer for now. That is, until v3.2 where proper UI will be designed for this.

GEGL operates on DAGs. Claiming that it doesn’t work in a non-destructive manner is like saying that water isn’t wet or sun isn’t hot. You can even animate parameters of GEGL operations. There’s a whole built-in UI for that (and more). It’s kind of a public knowledge.

I’d be interested to know what libraries other than GEGL the effects stack in GIMP is split between, in your opinion. Surely you wouldn’t mean babl that has nothing to do with effects and everything to do with pixel data conversion?

There’s been no less than 3 contentious forks of GIMP (the most current being glimpse) that were born from the maintainers’ inflexibility and refusal to change or improve various aspects of the software.

Lemme guess 🙂

1) Cinepaint, formerly FilmGIMP. Started from the HOLLYWOOD branch of GIMP created by R&H developers. The very same R&H developers then created GEGL to do everything right, using the right architecture. The very same ones, Tyson.

2) GIMP-Painter, I guess? That guy wanted to pursue his own goals. When he suggested to reuse his MyPaint code in GIMP, he was actually supported by GIMP’s maintainer and lead developer. That never worked, but GIMP ended up with its own implementation of the MyPaint brush tool. GIMP has more features originally developed in that fork, including brush stabilizer (added in v2.8) and canvas rotation (added in v2.10). The former being a heavily modified patch, the latter being code written from scratch after looking at the code in the fork and deciding against it.

3) Glimpse. The primary objective of that fork is to rebrand GIMP. They claim they want to make UI fixes, but they haven’t made any yet. We’ll see how it goes.

I really have no idea where you are getting the impression that GIMP devs refuse to change and/or improve the program. It’s all they’ve been doing for years: changing and improving. Maybe you just don’t like the pace?

Look through the issues and pull requests in their repos and mailing lists if you want specific examples.

Nooo, I don’t think this is gonna work. I’m well aware what PRs the team gets and how the team responds to feature requests and bug reports. But please, go ahead and show me those horrible examples of the team refusing to accept patches:

https://gitlab.gnome.org/GNOME/gimp/-/merge_requests?page=2&scope=all&state=closed

jack is a huge pain to use

Once you set it up for the right samples and periods values (takes a few minutes tops), you just start and stop it. In fact, with Ardour, you don’t even have to use JACK at all these past, oh, 5 years now?

there’s no commercial plugin support anyway

Now, if you said there’s little commercial plugin support, I would totally agree with you. That said, Pianoteq has been my go-to virtual piano plugin for the past 7 years, and U-he synths are smth I’ve been meaning to lay my hands on for quite a while. I haven’t found the use for OvertoneDSP or Harrison’s effects yet. But those are all commercial options, with support.

and any LV2 stuff you can scrape off github and compile successfully

Strangely, I don’t feel like running TAL NoizeM4k3r, Helm, Surge, OB-XD, or Dexed etc. requires scraping off something from somewhere. They are fine, powerful instruments, usually with Linux builds already available. I wish there would be more of them, yes. In fact, Vital is shaping up nicely.

Now, I do know full well that linux audio isn’t first class citizen. But strangely, the issues you are naming are mostly from years ago. Why is that?

Sure, they admit it, but they don’t change anything that practically improves GIMPs usefulness in production.

Would you like to provide specific examples?

Nor do they let people commit code that would if they don’t want to.

Again, would you like to provide evidence of that?

The fragmentation on feature support between Pulse, Jack, OSS, Pipewire, etc. means you have to spend more time fiddling with the sound system than actually working.

What does that fiddling actually involve in your case?

Sure, they admit it, but they don’t change anything that practically improves GIMPs usefulness in production. Nor do they let people commit code that would if they don’t want to. The project is managed badly and has over a decade of technical debt. I don’t think it’s unreasonable to characterize it that way.

The fragmentation on feature support between Pulse, Jack, OSS, Pipewire, etc. means you have to spend more time fiddling with the sound system than actually working. Linux is easily the worst environment to run a DAW in.

As a project like GIMP or MLT reaches code completion, the maintainers become less receptive to criticism or change. They don’t want to hear that they implemented something incorrectly, or in a way that makes their software less usable.

Oh dear… More than a dozen times in my life, I’ve seen GIMP maintainers publicly admitting they wrote shit code that needs to be rewritten. And your takeaway is THAT? May I ask what your statement is based on?

The Linux sound architecture cripples native DAW functionality

Exactly how does it do that? 🙂