AU example plugins crash on M1 in reaper/logic, when arming/unarming track

[reFX]

@anon48770766

Sure: it allows us - as developers - to ensure that the thread semantics we expect actually equate with those which are granted us by the operating system, and if we have written well-behaved, multi-threaded code (we have) having the ability to set the AudioWorkgroup ensures that we can continue to organize our threads appropriately - outside the context of the DAW, sure, but … so? Not all DAW’s are equal and having this fine granularity of control over how threads behave in our own local context is very, very beneficial - both during raw development, as well as during the porting process.

Sorry, but that is just a word salad. Please provide a concrete example of how having the ability to join the AudioWorkgroup benefits you as a developer. How is that any different than just creating a realtime thread?

@anon48770766

As for the discussions regarding feature/development/hacking branches - if you learn to use git properly and already have best-practices in place to do your own local testing, you don’t ever have to deal with these issues.

Sorry, but that is victim-blaming 101. You are saying it’s our own fault that the JUCE team is putting out buggy code.

@anon48770766

The JUCE team have done pretty well so far - we are on version 7.x after all

What does the number of releases have to do with anything? There are still bugs in the code that have been there since version 1.0, so equating a version number with success or using it as a metric for the number of bugs is very naive. I could release 15 versions of our plugins today, but that wouldn’t mean that one version is inherently better than the previous one.

@anon48770766

so really this is just developers moaning about having to learn how to git bissect when the automatic tests have failed… oh wait, you don’t have automatic tests, and have never done a git bissect? That’s the real problem.

And now you’re making baseless assumptions and again blaming the customer/user (us) for the failings of the JUCE team.

We not only have unit tests, but we also have smoke tests, meaning we render audio files out of our plugins for every commit and then compare them against a set of known good audio files and raise alarms if the commit produces differences outside a configurable margin of error. So we don’t only test if our functions return the expected values, but if the whole complex system produces the right output, given a complex input. Can you say the same?

My real problem with the JUCE team is that the reason they officially state for not accepting pull requests is that

1. The code quality is not good enough
2. Doesn’t fit the style
3. Lack of testing or lack of manpower for testing
4. That it might interfere with future plans they already have

But except number 4, these are all nonsense, and they have proven time and time again that even number 4 doesn’t apply.

1. If their code is superior, where are all these bugs coming from?
2. There are tools to enforce a style, even during a commit.
3. It should be very obvious by now that they don’t test their code as stringently as they claim. Some things are hard to test, I understand, but some of these bugs are extremely obvious.
4. I don’t believe that having future plans is a good reason not to fix a bug. One never knows when these future plans come to fruition, but in the meantime the bug could be fixed for thousands of developers and potentially millions of users of the products these thousands of developers put out.

More than half of all these bugs would be long gone if they allowed pull requests. They are sometimes very simple fixes, but NOOOO. What if this or what if that, instead of just accepting and merging the pull requests? Maybe the name of the lambda function we picked is not up to their style? How about you tell us, or merge and change the name yourself?

Bug that is extremely easy to fix, has no side effect, and affects literally every developer who has a semi-complex UI:

If you set a component to opaque and wrap that component in another component that has an alpha value, you see garbage where the opaque component should be.

Here is a forum post about it from five years ago:

setAlpha(0.5f) on an opaque component

… of course isn’t very clever, should give at least a warning, or maybe better, juce could handle the situation just right? Currently it produces redraw issues.

Jules seems to have added a check, but unfortunately, it doesn’t go up the parent hierarchy, so it only works in very specific circumstances.

Now we’ve found out the hard way and submitted this bug report:

Component setOpaque and setAlpha

Painting doesn’t work correctly if setOpaque(true) and a parent component has setAlpha (0.5f) set. There is a check here: if (child.isOpaque() && child.componentTransparency == 0) { g.excludeClipRegion (newClip + delta); wasClipped = true; } But this test is not enough, you can’t just test if the component has an alpha of 0, you need to go up the component hierarchy and make sure all the parents are alpha 0 as well. I believe it should be fixed like this: reFX: Fix drawing of opaque c…

Here is our fix:

reFX: Fix drawing of opaque components

And what is JUCEs official stance on the matter?

@reuk

This is on our radar, but there won’t be any related changes in the next point release.

Why not use our fix? What could it possibly break? Is the code bad? You don’t like the static free function? Make it a lambda instead, or a class function, or whatever, but it’s VERY easy to understand and fix.

There hasn’t been a single point release since the release of JUCE 7. We’re still on 7.0.x.

Hey, let’s not fix bugs that affect thousands, but let’s instead implement a new feature (AudioWorkgroups) and fix HighResolutionTimer inaccuracies, because heaven forbid if the timer is off by half a nanosecond.

The JUCE team is showing very poor judgment of what to fix/implement and what to put on the backlog.

By not accepting pull requests, the product suffers. You’re ignoring good, working code for questionable (at best) reasons.

Was @anthony-nicholls code also not good enough before you hired him? Now it’s magically good enough?

What about @attila ? Or @reuk ?

The culture Jules established is just not healthy. Even though he’s no longer part of the team, his rigidness lingers on.

Maybe start by opening the process up a little bit? Let established, proven developers, with a good track record, help you out. I promise you will be positively surprised and everybody will benefit.