The KVR Developer Challenge 2026 Is Go

[darkpalacestudios]

My view is that as long as a plugin doesn't turn into something fundamentally different from what it already is, this shouldn't affect its standing in the competition. For example, if a plugin like "Parrot" gains a new option — something non-obvious, perhaps, but still within its existing scope of functionality — something that doesn't change what the plugin fundamentally is, but merely adds to or fixes it — then in practice that changes nothing of substance. If a plugin like "Parrot" was good before, it's still good after adding option C: everything continues to work as it did, plus there's now something extra, or something has been fixed. The situation might look somewhat different only if the plugin evolved from a small frog into a dinosaur — that is, turned into something fundamentally different. But since the way points are awarded can be freely changed or rearranged at any time anyway, I'm not even sure I'd rule that out either.

Funny you mention our PARROT, we currently have a little bug in our build where the input gain slider doesn't work, haha (the output gain slider does work, though). We have already fixed the bug for our v1.0.1 build, which we will release soon. Though, if there are people that don't download the newest build, it's totally fine. Our work can be tested and enjoyed as intended on v1.0.0, also without a working input gain slider.

That said, we're all humans trying to improve and make our work as representable as possible for this challenge, small issues can always happen and is also part of this lovely journey!

We hope everyone is having a great time trying out all the cool plug-ins, we definitely are!

[1eqinfinity]

I still think that the easiest definition of a "new feature" is anything that was not in the initial UI.

Maybe this is a bit too strict. At the end of the day, it's not about winning these $400 or the title (the competition is too multidimentional for a single winner), it's about having fun and respecting each other.

If you need to add a ton of internal stuff to fix a corner case with some MIDI modulation - it's fine. But if you add a "relative" MIDI mode next to pre-existing "absolute" - it is a new feature.

If your LFO shape switch didn't work correctly, fixing it is fine. If you add a new LFO shape - that's a new feature.

If an author decided to cheat and had added a whole bunch of LFO shapes to the UI without any actual implementations inside - he/she is going to pay the penalty by simply getting lower reviews for such intentional "bugs".

Having said that, just yesterday I found a minor regression in my custom user layout functionality. I give a user the option of putting together a custom control panel to keep the controls that matter for their use case. However, I realized that the vertical spacers disappeared at some point later in pre-release builds, and I did not notice that in time. So I released the plugin with horizontal spacers, but the vertical ones were not there, and they were not even in the context menus. So by my own definition fixing this regression is cheating

[nr1killabee]

I understand and respect the rules for this contest but it is a missed chance if you ask me. For me the KVR was always an opportunity to interact as a user with the developpers. report bugs and ask for small features (like drag and drop of samples).
This should inspire the developper to work on his entry in the voting period and gives him the possibility to receive lots of feedback from us users.

I can't remember other DC's where this discussion was so alive?
Maybe Ben should indeed clear up some rule details ?
Because adding a "relative" MIDI mode next to pre-existing "absolute mode shouldn't be considered as a new feature right?

I also believe that when you (as a developper) miss the interactive opportunity with the users, most of the developpers will consider their entry as "done" and will not return to it after the contest to add stuff, that is ofcourse only my opinion.

On the other hand, when you delivered a product that is 100% done with no bugs or missing features...I do understand the frustration

[Frits van Zanten]

Stupid question, but what is the appropriate place to give feedback on or comment the specific entries/plugins?

[nr1killabee]

When the developper didn't already, just make a thread in the KVR Developer Challenge 2026 with the name of the entry as a title, that's how I did it.
There is also the option to write comments on the product page, but those are hidden so much that others will not see them.

[tatanka]

This might be interesting for anybody who wants a "preselection" and maybe some good tips on some stuff too:

https://www.pluginguru.com/videos/

livestream is coming tonight (ususally around 9 PM european time) from one of the real gurus of sounddesign, John "Skippy" Lehmkuhl.

The livestreams are sometimes a little confused (and loooong...), so usually not really my stuff, but in this case I think he will have to be concentrated when testing 19 of the plugins in one stream....

[IrionDaRonin]

Voting not working? Everytime i press a number it does nothing except going to the top of the page and the vote is missing. :S
Tried Edge and Firefox web browsers.

[audiojunkie]

What are the rules again for updating the synth with new features? Disqualification? Why does it exist? Is it because the participants feel it would somehow be unfair? If it will improve the synth and give the people testing the synths what they, request and want, how is this a bad thing?

It feels odd to tell someone, the request you made, drag and drop a waveform from the daw is a good one that slipped my mind and I can implement it quickly, but I can't because I'll be disqualified as its against the rules. Because it kind of doesn't make sense, alteast to me, I can't help but say it yet feel it might reflect poorly on the contest somehow.

Hypothetically, what if all the participants agreed we can add new features and not a single one of us really minds if others are improving things if it means we can too? Could the rule be lifted? Is there even one of us who would oppose the idea? If not, then what is the purpose of this rule?

I'm torn between working on a separate branch to add these features but then it will complicate things juggling between two versions. If I find a bug, I'll need to them fix them two places

Just wait until after the voting, and then you won’t have any problem, adding all the features you want forever and ever

[audiojunkie]

What are the rules again for updating the synth with new features? Disqualification? Why does it exist? Is it because the participants feel it would somehow be unfair?

I think it makes sense to freeze the submissions at a date, so the judging can be done fairly, with a fixed set of plugins. It’d be a lot harder to judge with all the plugins evolving. Doing that essentially crams all the testing to the last possible moment.

Having a separate branch makes a lot of sense, if you want to keep working on the plugin? It does seem like there is some wiggle room and minor improvements might be okay, even if they’re not purely bug fixes?

The idea to freeze submissions makes sense in theory, but I think we would need to define what we mean by fairness. How exactly does it become unfair if a plugin changes?

How the plugins evolve could even be part of what people consider when judging their favorite. If something evolves quickly, that could be seen as a bonus. Keeping track of updates does sound like a headache, and I understand that concern. But I wonder if, in real-life practice, it would really be that big of an issue. Someone might say, “Oh, I tested that plugin before it had A, B, and C features, so now I need to go back and test it again or else it’s unfair.” But I don’t think everyone will feel compelled to do that, and that’s okay.

Not every plugin needs to be tested equally by every person for the process to be fair, right? People are probably going to test whatever catches their eye or interests them. Some may test everything deeply. Some may only test the synths, or only the effects. Some people might vote because a plugin looks cool, because the demo video impressed them, or because they already liked the idea. I’m not saying that as an accusation either. I’ve probably voted before based mostly on what looked interesting to me rather than exhaustively testing every single entry.

So if the goal is perfect fairness, the voting process already has a lot of variation built into it. Different people will judge by different standards and different levels of testing. In that sense, I’m not sure that allowing updates is automatically a bigger fairness issue than the normal unevenness of how people actually vote.

To me, the biggest issue is twofold. If the devs don’t mind other devs adding features, then maybe that should not be the stated reason for limiting updates. If the reason is that it would be chaotic to keep track of updates, that is a real issue to consider. But I think it would be good to flesh that out more.

Is the average tester more bothered by plugins continuing to change, or more appreciative when the entries they like receive fixes, improvements, and feature updates?

I’m virtually certain most people are not going to monitor every possible update for every synth or effect so they likely won't incur the headache that might be imagined by having plugins evolve. In practice, people will probably follow the entries they’re actually interested in. Maybe the real question is whether people value a fixed contest more, or better plugins.

Personally, I’d say: fix bugs and add features with no hard limits, as long as it doesn’t change the original entry classification. It would probably miss the point if a synth turned into an effect, or a reverb turned into a time-warp glitch thing. But honestly, even then, if it makes the plugin better, why not? If someone thinks there should be limits, I think it would help to explain the reason clearly and then define what is allowed and what isn’t at a basic level.

So I’m not saying there should be no structure or limits. I just think the reason for the limits should be clearer. If the concern is fairness, what exactly becomes unfair? If the concern is keeping the contest manageable, that makes sense too. But then maybe we should ask whether users would actually accept that tradeoff if it meant the plugins they care about could keep improving. My guess is that many would rather receive better versions of the entries they’re interested in than freeze everything just to make the whole list easier to track.

This is just my personal feelings, but I believe that the submission should stay as is until after the voting. And the only things that should be done to the plug-in until after the voting is bug fixes, I think that would be most fair. And after the voting is done, do all the updates you want forever and ever.

[audiojunkie]

If I cast a vote early, I would expect that vote to remain representative of what I thought the plugin to be until voting is over. I'm certainly not going to monitor the entries for version changes. I was actually surpised to find out changes of any kind are allowed after the deadline. Significant changes doesn't mean the same thing to everyone and gray areas only ever lead to problems. I also think that developers who got their shit together before the deadline should be able to reap the benefits of doing so. Just my $.02

Not that I wouldn't want updated plugins after voting is over mind you. lol

After all is said and done, would your vote change? If it was your favorite now how would adding new features change that and somehow be offensive to your original idea you had when voting and not simply make it better and cement your vote? If you maybe might not like the idea of now facing the offensive idea of finding a better plugin that after all is said and done because the rules allow features updates, how is it you are losing out? Are you not gaining by liking something even more than you original thought on a different synth? While its true your vote changed, you gained a synth? Is the tradeoff worth it?

How early is the vote cast? If its too early then it's likely based on the type of how real life voting takes place I was refering to. Ideally, one would only vote until after enough time evaluating, not this plugin looked the best so I will vote for it the first day but I would be upset and it would be unfair to me somehow if my vote is no longer represetative after 3 weeks of updates on what I originally think it is.

How will they reap the benefits more than anyone else? Some people might not have been aware of the challenge until later on or only decide to enter after a period of time. Then it's a random chance whomever happens to be aware and decide to enter first would have the benefit. Another month won't undo that that advantage. Reap the benefits? Of what, winning a million dollars in the contest? I'd be happy to give the money away if it meant I could update the synth and respond in real time to feature requests and not build a parallel branch that I may or not be able to share and test as long as the contest is running. After the contest, not all devs might be as interested in adding features as eagerly as before, just sayin The best time for it is likely now when there is more interesting running.

What is more important, you possibly getting more features now because of the incentive as its running, or because you might be upset your original early vote no longer represents your original vote?

Ask yourself, as a developer entering this contest, why you feel so strongly about adding features at this moment rather than waiting until after voting. I think it’s all quite obvious, but it may not be obvious to you and I don’t mean that as a bad thing it’s just that everyone who has entered the contest it’s so heavily vested in the whole thing that they may not be able to see what is obvious to us voters.

I feel that to be most fair, the submission should stay the submission until after the voting. I don’t mind bug fixes to make existing features that might be broken, Work, but any additional features should be saved until after the voting has been done. That is the most fair way to do it. I know that you want to add features because it makes a plug-in, more desirable, but this is why there is a time limit for submissions. Otherwise the contest could go on and on and on. It is better in fairness for everyone to add features after the voting is done. It’s only gonna be a little while longer and then the voting will be done and then you can add all the feature she want forever and ever.

[audiojunkie]

Got it. your vote is the potential complexity is not worth it. Valid. Mine is it might.

I don’t see this as a matter of votes or personal preference. The competition has rules, and they’re there to keep things fair and unambiguous for everyone. If developers want to add significant new features, they can do so once the competition is over. It's really simple.

This.

[JsinOwl]

Are we allowed to discuss how we voted (or plan to vote) while voting is still going on? I'm surprised I haven't seen a lively discussion already started, so I thought maybe it's frowned upon or something.