Kontakt 8.2 Komplete UI (KUI): Low Quality Online Documentation, Buggy Demo

artisticaudio · 2025-02-17T04:29:19+00:00

There was an error rendering this rich post.

🖖!

Feedback for NI:

The only 1 official KUI demo instrument is still buggy even after release (^video^: streamable. com/aijc7s). (Knob issue @ Drag, if ZOOM != @1x)
Every single widget code example in documentation should come with multiple working demo projects.
Due to the complexity of KUI, the documentation should provide multiple detailed KSP and Komplete UI code examples, with fully explained KUI & KSP connection related detailed comments. It should also include working .nki / KUI project files, high-resolution images, and videos. This is a Front-End UI syntax, so documentation will only be clear if it provides detailed context rather than being excessively condensed into a few short sentences.
KUI Overcomplication: Documentation is in this case life saver for All: The KUI syntax is not readable, not consistent, and not logically structured. While simplifying it is no longer an option, this makes detailed and modern documentation exponentially necessary. The system cannot be understood for most users through the current approach in the online documentation. I haven't given up yet, because I’ve love math/logical games since childhood and can deduce missing context,but it causes a lot of unnecessary extra work.. However, based on comments and feedback from others, I see that many have given up learn KUI. I also notice that people are not entirely honest; they hesitate to express the facts they actually "feel". The same applies to me—I’ve phrased this feedback much more diplomatically than what the documentation and KUI’s and the single demo's actual state would deserve.
The documentation is only clear to those who develop the system or have close ties to the developers and receive insider informations/tricks etc…. Many things are not clear, and when people ask questions, they often only get partial answers because there is no proper reference.It feels as if only the developers truly understand the code, but they don’t have time to write documentation. And when they do, their extensive internal knowledge means they leave out crucial details, assuming them to be obvious.

Please involve artists and graphic designers in the development, not just artist friends,insider devs, or insider devs friends. KSP is not only used by insiders.😎

🖖

Find more posts tagged with

Kontakt

Comments

artisticaudio

The XY Pad is just as buggy as the KNOB.

The cursor does not move precisely. It behaves completely differently than in KSP.
The cursor lags behind the mouse.
After changing the mouse direction, the cursor almost completely shifts to the right and stays there until you release it.
When moving diagonally, the cursor drifts as if being pulled down by gravity.

I sincerely regret that even the official demo instrument has so many issues.

lswissdev

Same here, and, +1 issue in KUI based .nki demo:

If the value edit is 9< in the demo Komplete UI instrument, the XY pad jumps further to the left, this is unnecessary behaviour (just UX issue). Widget positioning:

demo_instrument: Positioning is CSS like. Unfortunately. This is a sampler, not a 30-page long website, the KSP way is better. The GUI is always 1 page - sized.

lswissdev

and the XY pad drag behaves unpredictably/randomly cursor movements - If the Kontakt View > Zoom is not set to 100%.
The cursor feels 'slow' and 'asynchronous' compared to mouse movements.

lswissdev

"the XY pad drag behaves unpredictably/randomly cursor movements"

Slider the same: unpredictably/randomly movements If the Kontakt View > Zoom is not set to 100%.

lswissdev

(demo instrument, Komplete UI, KUI)

Matthew_NI

Hi Folks!

Thank you for the feedback.

Indeed, we launched v1.0 of Komplete UI last week. This is pretty exciting, and a number of people are already building with it.

It solves a number of problems, including a very fundamental one: KSP runs in the audio thread. At best, this is limiting features we'd have liked to build prior. At worst, if problems or bugs with UI built in KSP happen, they can contribute to audible glitching. KUI both avoids the resource inefficiency, and allows us to build new features builders have been asking for.

We also have a pretty robust roadmap of continued updates ahead. In 2025, we want to meet and then exceed feature parity with KSP. On that roadmap are also expanded tutorials that I think you'll find helpful.

Regarding this:

Please involve artists and graphic designers in the development, not just artist friends, insider devs, or insider devs friends. KSP is not only used by insiders.

KUI in beta until last week, and we've worked with a tight group of contributors that may skew more "insider" given that it's beta. That said, it's been a very cross functional group of builders, sound designers, graphic designers, etc. We're now public, so that'll help even more.

We do have a private NI Developer Slack; I think one of you is already participating in there as of last week. That's a really good place to not only give feedback directly to the KUI development team, but seek help and advice. Are you both in there? If not, let me know and I can get you signed up.

Regarding the XY bug; we've been able to repro this on Windows, and have filed the bug. The aforementioned Slack is a great place to report issues such as this, as they may get missed on this forum.

Best,

Matt

artisticaudio

Dear Matt & NI, 😊

Matt:

Thank you very much for taking the time to review our feedback. I truly appreciate it. As a loyal user for over 20 years, I believe in continuous improvement. Although the KSP documentation has a more backend-oriented approach, it was still comprehensive enough to allow users to learn and experiment on their own—for example, creating self-made range sliders via the XY Pad (or even building an XY Pad from scratch without an actual XY Pad 😄).

Native Instruments:

KUI Complexity & Documentation Issues

Many posts discuss topics such as how to create a KSP > KUI converter or whether it’s even necessary to use KUI for building instruments (fortunately, it’s not mandatory). Yesterday, I gave KUI another chance and looked into the rounding functions in the manual. For example, the negative and positive examples are mixed up—the I and O are written in different orders, which disrupts the logical flow and makes the information ambiguous.

Conclusion:

This was the N+1 quintessence of KUI and its manual for me: unnecessary overcomplication everywhere. After much thought, I’ve decided to step away from KUI—for at least a year—because, as of now, I feel it is simply not worth it.

1.) I have no problem creating vector and PNG graphics myself; I don’t need to generate shapes for knobs or buttons within KUI. The vector font support is absolutely brilliant—I love it! That feature alone made me excited about fully transitioning to KUI.

First Steps & Growing Concerns

However, my enthusiasm quickly faded after seeing the demo instrument. The sheer number of bugs made my instincts scream: "Don’t do it. This will end badly."

Five widgets produced at least 15 different types of random behavior, bugs, or UX issues.
These issues represent exactly what makes KUI and its documentation feel overcomplicated.

I develop sophisticated user interfaces—sometimes extremely complex ones, either for myself or for friends. For very basic graphics, KUI might work fine in a minimalistic UI style, as fewer elements mean fewer bugs.

Complex Interface Issues & Debugging Struggles

However, for complex UI design, I fear the random bugs.
Yesterday, we spent over an hour trying to figure out how to position a widget within an X-Y system without causing glitches—and we simply couldn’t do it in a way that wasn’t bugged.

I still remember when I first started working with KSP—positioning elements perfectly took about 10 seconds. Not 5000 seconds with errors. 😞

If something this simple generates so many issues and takes so much effort to implement, then this inevitably comes at the expense of functionality and creativity.

Matthew_NI

A better forum to discuss this might be our NI Developer Slack - would you be OK moving the discussion there? That is still a public forum (I'm not looking to hide anything) but it's also a more focussed area for exactly this purpose.

Quick links

Unanswered questions