My apologies for the confusion, I can see how you read what I said that way.
I’m actually suggesting juce consider the above, I’m not complaining as if they are already doing the above.
My point being it’s the kind of thing no one would take issue with paying for, but they may not go through the extra steps to support it in large enough quantities to actually keep it going to the level we all would like to see.
A few things I would add to the list that would get my vote:
I like the idea in principle, but given the wide range of use-cases for JUCE I don’t think it would work. E.g. if you’re not building plugins with JUCE then pluginval is of no use to you and so ahving to pay more for your license to support it wouldn’t be great.
According to the roadmap (JUCE Roadmap Update Q3 2025 - JUCE), JUCE are planning on adding a marketplace, so maybe sponsorships could be a feature of that? A lot of donationware will have a “recommended donation” as a default, but allow you to enter 0 if you don’t want to pay. So maybe the marketplace could have a similar thing of allowing developers to set a recommended donation amount on their projects
@theaudioprogrammer, I did think @Algernon’s post was a negative comment at first as well but after re-reading it understood the suggestion of a “JUCE license funded, user-distributed system”.
It’s a nice idea but could be tricky to implement and I have a feeling that any increases to the JUCE license wouldn’t go down well, especially if customers are only using JUCE.
I think it’s because you opened with this sentence that it sounded negative 
I’d love to do this but (and this may be unpopular) I’ll probably wait for C++ reflection to land as it will be so much easier to do this (or maybe write what I need to in cpp2 as it has the option to generate Python and JS bindings now).
It’s a fair ask but probably quite a bit work work as there are a ton of things you could test. With the JUCE accessibility layer this is now easier but are you testing just for the presence of controls or if they affect the sound correctly?
I remember a Focusrite demo from ADC several years ago but will have to take a fresh look at that.
That’s a good idea. I can see how this would work if you have old reference material (like in a json file), it would be much hared to compare two actual plugin binaries though. I’d have to chat this one through to see exactly what you and others would have in mind.
That’s a good point and one I’d forgotten about. Be keen to hear from JUCE if they’ve thought along these lines.
The marketplace itself isn’t going to handle any payments, but we could add some flag to indicate that a product is seeking donations.
That would come in a later update though. We’re close to having the first version ready and I don’t want to delay it any longer.
There’s a link to Joe’s talk on the README: GitHub - FocusriteGroup/juce-end-to-end: Library to assist with end-to-end testing of JUCE desktop applications. For plugins I think the most valuable thing would be the controls<->parameters connection. I.e. if I set slider X to 123, does parameter X get set to 123? If the host changes parameter Y to 456, does slider Y get set to 456?
Yeah loading two versions at once maybe wouldn’t work - but maybe having a mode to generate some reference JSON as you say which can then be loaded alongside a newer version to check compatability could work. Probably easier for CI too rather than having to download and install an older version of your plugin.
Right, but that’s not really how parameter usually work behind the scenes. There’s all sorts of snapping and normalisation going. Figuring out what that check should be is half the battle I imagine.
Fixed the post.
You may be right, unless JUCE, in time, sees enough other similarly scoped projects pop up across enough subsections of JUCE users. The beauty of the system is it feels like it’s JUCE making the donation, not the customer. The customer is just directing where it goes (or it goes to the default location).
Anyway, just trying to think of ways that makes it easier for us to all have nice things. Even a shout out from a JUCE email could be good here, to get word out?
Yeah we’d have to write those tests ourselves on a per-plugin basis - which goes back to my first request to be able to write custom tests using a suitably high-level language where pluginval offers an API to expose parameters, elements of the UI, etc. so I can write high-level tests that wouldn’t be suited to unit testing.
I think that’s largely the intension of the marketplace. There’s also GitHub - sudara/awesome-juce: A curated list of JUCE modules, templates, plugins, oh my! which more people should star, watch, and contribute to!
I created an app a while ago that did exactly this with the intention of integrating it in to our CI but didn’t have time. Happy to share if it would help because I think this is a super useful feature.
This is a very interesting thread with diverse and inspirational views.
Just my 2c:
The reason I would like a wallet (yes, crypto wallet) address to be an accepted best-practice for JUCE developers, is entirely about wanting to have a direct relationship with the dev vis a vis a donation. I don’t want 3rd-parties involved when I’m doing a donation (Github, etc.) - I do want to know the developer got the donation directly from a happy customer. My main purpose with this point of view is for us as a community to find it acceptable for developers to do it. Just drop your wallet hash in the About box, and let those who want to use it, use it. Actually it doesn’t have to be a crypto wallet - just an accepted best practice that JUCE devs can take donations, too, if they want to - and that nobodies hair lights on fire if this starts happening in plugins. (Yes: JUCE License applies on top of this.)
I have been using a combination of pluginval/auval, and my own plugin hosts for continued JUCE testing and validation, and while things are working fine, I see some things that could be useful.
I find that as a plugin gets developed, its sonic nature changes over time, and having a record of that - alongside git hash ID’s of course - is often very useful in debugging and development. In a couple of projects, just getting things up and running with source code → CI such that daily ‘official installer/packaged’ builds work, from day one of development, really helps things out. Devs can focus on code - other project members can take the CI builds and test, test, test. Because plugins have got to be tested, tested, tested.
For deep testing and plugin validation, of course one must use a real DAW, and from the automation perspective in that sense I have REAPER very well scripted (Lua) with some sample sessions set up for various edge cases and main-use cases of the plugins.
This is mostly useful because it can really be scripted in the build/CI system, happen alongside mainstream development testing, and doesn’t require much hand-holding - other than, of course, to update the test/project settings, automation, etc. as the plugin features get tested. Setting up the DAW for tests and doing plugin development, are two concerns that are wisely separated between minds, I feel. Its better to have an end-user doing manual testing alongside you in the dev environment, but if we plugin devs can’t get that, fully automated testing is worth the effort as well.
I continue to amass a collection of REAPER scripts and test sessions, which all get rendered and exported to a stereo master track, which I can easily audition/replay during development in projects.
So on one end of the spectrum, pluginval fuzzing is awesome - but on the other end, one must DAW.
So .. all of this is a big wind-up to say: It would, perhaps, be nice if pluginval itself were a plugin, so that I could lay out these automated DAW test sessions and have a pluginval fuzztest (or hard-coded seed value) play back, in the track as well.
This way I could pluginval-during-CI (i.e. just plugin the seed and run plugins standalone), but also pluginval-mid-DAW, during testing/development, to make sure things are in a known valid test state.
Does this make sense? Plugin testing environments is a subject that doesn’t get much love and attention - but I can say we are all very definitely granted massive gains by the pluginval tooling, in and of itself… so maybe the future looks really bright for the testers ..
I’m not quite sure what you mean by this… Could you elaborate on what pluginval is actually hosting and processing in this case? How is it interacting with the host itself?
The idea would be that it could be used to fuzz test a plugin in the middle of an automated DAW-based project, basically .. with the ability to re-seed according to prior seed values that failed the test. I’m not really sure how it’d work - plugin-to-plugin parameter changes somehow, perhaps a sharedMemory extension that could be used?
But the idea is to be able to have a reproducible fuzz test in the middle of other more DAW-aligned tests…
Ask (and provide suitable incentive) and it shall be given:
