The KVR Developer Challenge 2026 Is Go

[JsinOwl]

We now have a KVR thread and a video for Double Freak.

You know, I'm trying not to install all 56 of these goddamn plugins, but apparently there's another one I need to take a closer look at.

[Pytchblend]

A tip to all the devs... add a video please -- a video is worth 1000 words.

[marcedwards]

We now have a KVR thread and a video for Double Freak.

You know, I'm trying not to install all 56 of these goddamn plugins, but apparently there's another one I need to take a closer look at.

Thank you! We have help pages with more info, and feel free to ask me if you have any questions.

A tip to all the devs... add a video please -- a video is worth 1000 words.

Yeah, definitely! They’re a fair bit of work, but a quick tour can be great.

[Jay Nava]

greenland by ovm is simple and fun as hell. The randomizer goes hard, its definitely useful when i want to generate something actually random and useable. I do wish there was a built-in arpeggiator tho that would be even more fun paired with the randomizer.

[Touch The Universe]

I’m trying to get a clearer sense of where the line is between acceptable maintenance and adding too much after submission.

Since entering, I’ve made a number of changes. Some are clearly bug fixes, while others are small or medium workflow/features. I can keep two branches if necessary—an official contest build with only approved changes, and a separate development build—but I’d like to know which of these are acceptable in the official entry.

Bug fixes / maintenance

Removed an unintended root-note layer in MIDI mode
Fixed MIDI timing and synchronization
Fixed release tails and note-off behavior
Fixed attacks retriggering during release
Fixed frozen playheads and tabs that blinked without activating
Fixed MIDI audio not reaching the intended effect engines
Removed hidden dry audio when all effects were off
Fixed launch quantization on long samples
Fixed preset routing recall and older-preset compatibility
Fixed Master Clear not clearing every curve/layer
Fixed crackling and several compile issues

Smaller workflow/UI additions

Drag-and-drop sample loading
Solo/Unsolo on effect tabs
Double-stop to rewind
Tempo-based launch options
Pattern Sync options
Expanded polyphony choices
Browser color/text/layout improvements
Keymap window opening in front
Stretch wet/dry and output gain

Larger workflow/features

Master Amp ADSR
Master filter, resonance, and filter envelope
Export Bank / Import Bank
Automatic WAV/AIFF-to-FLAC conversion when exporting a bank
Portable relative sample paths
Sample Start/End handles and non-destructive trimming
Additional Stretch source modes such as Root Bed and multi-octave beds

Could someone clarify which of these categories—or which specific items—would be acceptable in the official contest build?

I also think there is a broader question about cumulative changes. One small improvement may obviously be fine, but what about ten, twenty, or a hundred small improvements? At some point, many individually minor additions can collectively become equivalent to a major update.

Is there a practical limit or principle we should use, such as:

only bug fixes and compatibility fixes
a small number of minor workflow improvements
no new sound-design capability
no meaningful expansion of the submitted feature set

I’m not trying to push the rules. I want something concrete enough that I can maintain a fair official build while continuing development separately. Right now, “small improvements are okay, major enhancements are not” still leaves a lot of ambiguity when the changes accumulate.

The Export/Import Bank feature is particularly important because presets reference external samples, and without portable packaging it is much harder to distribute the factory library cleanly. But I understand that it is still a new workflow feature, so I would appreciate a specific ruling on that one as well.

[Touch The Universe]

One additional point, just to be honest about the practical side of this: right now the contest is creating attention, feedback, and momentum. People are trying the plugin, pointing things out, and giving me reasons to keep refining it. That is exactly when I am most willing to spend the time fixing things and adding improvements.

After the contest, if that attention disappears, there is a very real chance I will simply move on to another project. I do not say that dramatically; that is just how creative momentum works for me. The idea that everyone who is holding back features now will automatically return after the contest and continue development may be optimistic.

In that sense, the contest period may actually be the best opportunity for some of these entries to become substantially better. At the same time, I understand the fairness concern: once enough additions accumulate, the submitted entry may no longer be the same thing people originally entered against.

Maybe one possible solution in future contests would be a separate category or label for entries that continue active development during voting—something like “development build,” “non-prize development entry,” or a secondary showcase list. That way, people who would rather keep building than compete for the prize could still participate, receive feedback, and remain visible without creating ambiguity around judging.

I am not insisting that this is the answer. I am mainly trying to describe the real tension: preserving fairness matters, but so does making use of the brief period when users are actively engaged and developers are motivated to improve their work.

[Touch The Universe]

To be completely candid, if I decide that the official build must now be frozen to bug fixes only, then I am probably finished developing Focus Time for the foreseeable future. The feature work is what currently holds my interest. I am not realistically going to stop now, wait until the contest ends, and then return with the same motivation after the attention and feedback have moved on.

So the practical options for me may be:

keep the official contest build limited to bug fixes, then move on to another project;
continue improving Focus Time in a separate development build while leaving the official entry frozen; or
continue improving the public build now and remain involved only as a non-prize or showcase entry, if that is possible.

I would still value participating, receiving votes, and getting feedback even if I were no longer eligible for a prize. The concern, of course, is whether voters would feel their limited votes were being spent on an entry that could not receive an award.

So I would appreciate clarification on what actually happens if an entrant continues adding substantial features during voting. Does the entry become ineligible? Is it removed entirely? Could it remain visible and votable while any prize passes to the next eligible entry? Or should the newer build simply be listed separately and excluded from judging?

I understand why the rules need to protect fairness. I am not arguing that I should be allowed to transform the entry without limits, and I am not asking to quietly change it while retaining every competitive benefit. I am trying to find a transparent option that allows continued development, public feedback, and participation without unfairly displacing entrants who kept their submitted builds stable.

[1eqinfinity]

A tip to all the devs... add a video please -- a video is worth 1000 words.

100%, but also, a video with dev's voice over is worth three days of anger management and frustration.

[Touch The Universe]

A tip to all the devs... add a video please -- a video is worth 1000 words.

100%, but also, a video with dev's voice over is worth three days of anger management and frustration.

Haha How about an ai voice over

I usually don't do voice overs but this one Im going to make an exception

[Chicken Drummy]

Haha How about an ai voice over

I'd rather listen to a developer ramble on for 30 minutes about what his plugin does without ever once providing an audio example (we've all stumbled across one of those) than to endure an AI voiceover for 10 minutes.

For FL Studio's most recent update video, Image-Line clearly used an AI narrator based upon the voice of the man who usually narrates them (post-Worrall) and it's one of the most awkward update vids I've heard from the company.

The sound quality is terrible, full of artifacts. It's a slightly hellish tapestry of humanesque voices trying their best to mimic the narrator that IL recently removed from payroll, but failing miserably to anybody listening with working ears. It's uncanny valley in audio form.

So no, give me a rambling mumbly human any day of the week.