The KVR Developer Challenge 2026 Is Go

[Touch The Universe]

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

[marcedwards]

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?

[Touch The Universe]

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.

[JsinOwl]

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

[Touch The Universe]

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?

[ConceptualMachines]

Either everyone follows the rules, or we end up going down a philosophical rabbit hole about what’s fair and what isn’t. The whole point of having rules is to avoid that.

[Touch The Universe]

I think the cleanest middle ground would be to separate the official contest download from any bigger development builds.

The official contest page/download should stay limited to bug fixes, compatibility fixes, installer fixes, and small workflow improvements. No major new features should be added there once people are downloading and judging the entries.

If a developer wants to keep working on bigger features, they could post those in their own separate forum thread, clearly marked as an unofficial/dev build that should not be judged as the contest version.

That way, the official contest source stays stable. The majority of casual users who come to check out the contest will probably just download from the official page, so they will still be judging the plugin in its original contest state, apart from fixes and small improvements. They probably won’t go digging through a separate development thread unless they are already especially interested in that plugin.

So the official judged version remains easy to find and consistent, while the deeper users who are following a specific plugin more closely can still try new features, report bugs, and follow development if they want.

That seems like a reasonable balance: don’t turn the official contest entry into a moving target, but also don’t completely stop developers from continuing the work in a clearly unofficial place.

[ConceptualMachines]

If a developer wants to keep working on bigger features, they could post those in their own separate forum thread, clearly marked as an unofficial/dev build that should not be judged as the contest version.

I think that’s unnecessarily complicating things. If a developer wants to keep working on bigger features, they can simply wait until the competition ends and release them afterwards. Otherwise, new features will inevitably influence how people perceive the existing entry, and we end up introducing unnecessary ambiguity about what should actually be judged.

[Touch The Universe]

If a developer wants to keep working on bigger features, they could post those in their own separate forum thread, clearly marked as an unofficial/dev build that should not be judged as the contest version.

I think that’s unnecessarily complicating things. If a developer wants to keep working on bigger features, they can simply wait until the competition ends and release them afterwards. Otherwise, new features will inevitably influence how people perceive the existing entry, and we end up introducing unnecessary ambiguity about what should actually be judged.

Got it. your vote is the potential complexity is not worth it. Valid. Mine is it might. If you were interested in the features, you are more likely to get them during the run of the contest. I personally would fill more compelled to add them during this period, and share them immidiately, instead of maintain two branches though I know for sure some devs work on them afterwards. Mostly, its a one and done with zero new features.

[ConceptualMachines]

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.

[Touch The Universe]

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.

I see devs mentioning they would like to add features, or not sure what features might be grey zone, so a conversation fleshing out the rules might be in order. It's called improvement If even things are just clarified more. In that case, the more input is better. I did not shut down your opinion. Just letting you know I am hoping others might feel free to post there own if they have any as well.

[Chicken Drummy]

Them's the breaks, kid. The rules are the rules.

[Touch The Universe]

Them's the breaks, kid. The rules are the rules.

And what are they exactlly? Do you who are only concerned with following them know?

What constitutes a feature? Can one share a secondary branch?

[1eqinfinity]

Is it yet possible to subscribe a new KVRDC26 entry? I think it's too late for me...

Unfortunately it is too late, but maybe Ben is open for the "late entries"/"football league" section or something

[id3at]

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.