NI Kontakt - update to 5.8.1[updated from 5.8.0]

[Lawrence]

Call it a potato if you like.

[Thorsten Meyer]

Call it a potato if you like.

MAC Pasta

[Lawrence]

I AGREE, ANDERS.

Meanwhile, about this Kontakt thingie, I checked to see where I was and I'm on 5.7.1, which I seem to remember that in upgrading from 5.6, I was worried that it would screw things up with the whole Native Access thing, but it went very smoothly. Has there been any revision since then (short of 5.8) that's improved anything major? Does 5.8 do anything impressive? The list of improvements doesn't look compelling. I guess new libraries will insist on it, is the thing?

[Guy Rowland]

I guess new libraries will insist on it, is the thing?

That's always the thing. And updates too - any bug fix / new feature / new content updates are also always latest version.

The library search thing is new, but I don't think that's such a big thing really. Given the various problems reported, I'm not rushing to 5.8.0, will wait at least for a bug fix release after this.

I'm still pretty staggered at how slow progress has been on NA, K5 and KK, given the size of NI. We're in "what do they do all day?!!" territory. KK still doesn't have any way of viewing what library or plugin a patch belongs to and doesn't have a resizable gui. It's pretty much impossible to use effectively, after how many years now? The Kontakt library pane is still a library pain (ha ha), with crushingly slow times to re-order anything. You still can't point NA to an NI library to add it manually, nor use it offline. Really basic fails all of these, and little new innovation elsewhere too. IMO something's been up with NI's management for the past few years.

[Lawrence]

I think the "something" might be "monopoly".

[Guy Rowland]

I think the "something" might be "monopoly".

That's part of the picture maybe, but it doesn't really explain all of it imo. NA and KK aren't really in a monopoly situation, and they're equally rubbish. Something's wrong with their internal policies or resource allocations.

[kpc]

I'm guessing it's a number of issues and I would except Brooks Law comes into play.

Perhaps they had a mis-step/bad decision about the direction V6 should take - found themselves painted into a corner and had to start over again.

[EvilDragon]

But, it is quite interesting how many Kontakt users are OK, with this amount of stagnation, and years of waiting for a new version, I'm personally not very happy about that.

Really? You call having this many subversions "stagnation"? That is clearly a very wrong way to look at things. Kontakt 5 dev cycle has been anything BUT stagnant. Who cares if there's a minor change in the number, there has been a lot of great things added to Kontakt in v5 cycle, things a lot of developers have been asking for years. Even the main part of the GUI got spruced up (so that part at least isn't "ancient" as you say it is).

Hopefully Kontakt 6 will be a total re-design of Kontakt 5's ancient GUI , and improve all aspects of using, editing, managing Libraries, sampling, etc. also a fully scaleable GUI to make working with it a joy, rather a form of eye torture.

My personal thought about this is that there won't be a total GUI redesign. We already had some fresh coat of paint in K5.6 - things won't change from this direction. The only change we could expect is the instrument edit mode being tweaked to match the overall scheme introduced in 5.6, that's about it. Don't expect any changes in how samples are mapped or edited or how libraries are managed, because Kontakt is probably going to become more developer-centric rather than user-centric, that's what v5 cycle suggests.

[EvilDragon]

Over on KVR, Evil Dragon says there is an error with Kontakt 5.8.0 and some very old libraries not working. Fix on the way in 5.8.1, so a good idea to hold fire for now.

Just an asterisk, I don't think I said that the fix is coming FOR SURE in 5.8.1, but that NI is aware of it and that we will PROBABLY have 5.8.1 in due time. It is perhaps implied, but please don't take my personal assumptions as a confirmed fact, as you know I'm under NDA and cannot really share what will come in which version when, in public (in fact beta testers aren't privy at all to this info, we just know what is coming when we get a new beta, but nothing before that). It's all just a personal guesstimate, but still I can definitely confirm that NI is aware of the issue and are working on the fix, at least - as I was assured by Kontakt's product designer, the idea is that Kontakt will ALWAYS be able to open ANY library made for any version of Kontakt Player, so what we're seeing here is some sort of regression, perhaps it might also be tied to NA.

Perhaps they had a mis-step/bad decision about the direction V6 should take - found themselves painted into a corner and had to start over again.

Actually that is exactly what happened, without going into any more details.


That, plus Kontakt now has a 15 years old codebase. Doing any sort of changes can backfire in most unusual ways, so adding new stuff on top of that is much slower than it would be on a fresh codebase. However, that old codebase really has some things done EXTREMELY PROPERLY (like DFD and CPU efficiency, and nicely working multicore, which some other samplers are pretty oblivious about), so recoding everything from scratch is absolutely not an optioin. So, things take a longer time to ripen.

[tack]

There's been a reasonable pace of development but it just seems to me like most of the focus has been outside of Kontakt, and of the advancements in Kontakt they've felt pretty minor. No major innovations.

Hard to say without an internal scoop, but in addition to everything else mentioned so far, another factor could be a rickety and unscalable code base. (Scalable in the sense of modularity, so you can have multiple parallel branches with different teams focusing on long term innovation and another team doing short term features and fixes and being able to merge the changes back in with minimal regressions.)

I've seen it enough times where lack of modularity causes monstrous regressions with all but the most trivial of changes. The time wasted on testing and fixing the regressions is a death blow.

For an example of how to do this right, I have to point out Blackmagic Design's DaVinci Resolve. Over the past two years they have been making impressively massive improvements in their major releases, incorporating their acquisitions of Fairlight and Fusion into Resolve. These were basically rewrites of those products. In Resolve 14 last year they added Fairlight and throughout the year steadily released multiple new versions with minor features and improvements. Then recently Resolve 15 dropped with massive core changes, not the least of which is Fusion, but they made quite significant changes to all corners of the software. They were clearly working on this even before Resolve 14 released last year. IMO the only way this can happen is with a well designed modular code base and rigorous source code management.

In Kontakt's case it could be management complacency thanks to their monopoly, or unclear product vision, or poor working conditions causing the experienced engineers to leave (high company attrition will drastically stifle advancement on an established product), or a very poorly designed code base making innovation a major technical challenge. Or more likely a combination of those things.

[EvilDragon]

Also, Kontakt's team didn't have the same product designer throughout the years. Staff changed, sometimes quite radically (I'm in fact not exactly sure if any of the original Kontakt programmers are still in the team - perhaps just one of them, or at least one with the most knowledge of the codebase going sufficiently back, but maybe not way back to v1.0). Programming style of early 2000s software is most definitely not the same as how things are done today (this also shows in SC vs NA, etc.).

I've seen it enough times where lack of modularity causes monstrous regressions with all but the most trivial of changes. The time wasted on testing and fixing the regressions is a death blow.

Ding ding ding, we have (most probably) a winner. Although, NI does use subversioning/git/whatever internally, but that of course is not the golden bandaid every time.



On another thought - what exactly would be "innovation" in a product like Kontakt? Something like AET, which they did in v4, but sadly never catched on?

[Guy Rowland]

All fair dos, Mario.

Do you know if they plan to allow Add Library locally for NI stuff?

Innovation - without it spawning into some whole new monster, I think really its allowing for far simpler instrument building, with semi-intelligent wizards or something. From what you say though it sounds like they're more focused on dev tools, not user DIY sampling.

Otherwise its refinement, not innovation. Kontakt was best in class for efficiency as recently as 3 years ago, I don't think that's the case any more. Jason was doing interesting testing recently on its efficiency, and finding that there appeared to be considerable room for improvement. And one specific example - Play have it right (never thought I'd write those words) in allowing you to set preload buffers on a drive by drive basis, not a blunt global value. It would be ideal for Kontakt to have a mini tool to auto-set all the buffers really by having a test mode.

[EvilDragon]

Do you know if they plan to allow Add Library locally for NI stuff?

Absolutely no idea. I agree that it would be really useful. In any case, I did file a feature request for that in Centercode (beta tester bug tracker).

Otherwise its refinement, not innovation. Kontakt was best in class for efficiency as recently as 3 years ago, I don't think that's the case any more. Jason was doing interesting testing recently on its efficiency, and finding that there appeared to be considerable room for improvement.

Even with that supposed room for improvement, it's still more efficient than any other sampler. Although, HISE seems to be approaching fast.

Anyways, Jason purely tested loading performance, rather than streaming performance, which is different. It's streaming performance which we're the most interested in - and for that Kontakt is still second to none.

And one specific example - Play have it right (never thought I'd write those words) in allowing you to set preload buffers on a drive by drive basis, not a blunt global value. It would be ideal for Kontakt to have a mini tool to auto-set all the buffers really by having a test mode.

This is actually on NI's radar, however it's a pretty massive change of Kontakt's innards, so methinks they're saving that for K6.

https://www.native-instruments.com/foru ... es.317528/

Response from Kontakt's product manager is encouraging.

[tack]

On another thought - what exactly would be "innovation" in a product like Kontakt? Something like AET, which they did in v4, but sadly never catched on?

I think for Kontakt innovation falls into two categories:

1. Improvements that in turn help library developers to innovate.
2. User-visible enhancements that significantly improve performance and overall UX.

I'm not a library developer so I can't really speak much to the first. I know Paoling elsewhere made a comment that it'd be awfully nice if a script could measure the current sample value of an active voice so you could do some adaptive scripting. (Terribly sorry Paoling if I've misrepresented you. I may have forgotten or not understood to begin with.) I imagine there are a number of things like that, some of which may require significant internal changes to make possible. So the innovation may need to begin with a rewrite of the core engine to allow for some of these kinds of things that with the current engine isn't possible without hacks or adversely affecting performance. (Just handwaving here, of course I don't know any specifics.)

In my own experience, the first place I would start providing a new alternative to KSP. I honestly can't fathom how any developer accepts KSP. Even with my own modest multiscript project I found it painful and tedious to code in, extremely difficult to debug, and lacking even the most basic abstractions. It's like it was specifically designed to maximize developer pain. To make it tolerable, you have to use Nils' KSP extensions, but even then it's just lipstick on a pig -- and then you are moving out of the realm of what's supported by NI, so a developer would do that at their own risk. If I were NI, I would provide a more modern language to better support complex library code bases, and a better system for debugging. Performance is a nonissue: zero-cost or optional ultra-low cost abstractions are a solved problem.

But apart from the things I can think of, honestly it's the Product Manager's job to be innovative and to drive changes through a release that make the rest of us go "wow, cool, I never thought of that" and begin thinking about the possibilities.

In terms of Kontakt's legacy code base, this is another reason why DaVinci Resolve is an interesting case study. Resolve also dates back to the early 2000s. Ultimately this comes down to how you manage technical debt -- volatile, unmodular code bases being one fairly serious category of technical debt. This is almost always a constant battle between Dev and Product teams. Product's job is to push regular releases, bringing in new revenue, and it's antithetical to the unglamorous work of code cleanups, refactoring, improving modularity, all of which are invisible to end users and (by themselves) don't move product. So repayment of technical debt requires support from the highest levels of leadership, acknowledging that the compounding interest from technical debt will dwarf the cost of addressing it early, and allowing for an appropriate release cadence.

And maybe this is exactly what's going on with Kontakt? Maybe they're undergoing a massive rebuild of the code base to allow for that future innovation, and to us it only looks like they're sitting on their hands, meanwhile each of these 5.x releases is a much more significant release than it appears to any of us. And maybe by the time they get to Kontakt 6, they'll have paid down the major technical debt that's stifling their ability to move the product forward, and they'll start impressing us with cool innovations?

We'll see.

[EvilDragon]

There's some work done in debugging area. Can't say any more details.

KSP isn't going anywhere, I think. It's still more efficient than Lua for doing the same things with realtime priority (privately confirmed to me by Blake from Spitfire).

[tack]

KSP isn't going anywhere, I think. It's still more efficient than Lua for doing the same things with realtime priority (privately confirmed to me by Blake from Spitfire).

I'm no fan of Lua. And Python is too slow (although as a language I prefer it above most). I'm not arguing for one of these slow scripting languages.

Even just advancing KSP to bring some of the abstractions Nils' has introduced in a way that can be done more cheaply and supported directly. Proper functions would be a great start. The amount of resulting code duplication after compilation using the KSP extensions can't be zero cost in terms of performance (even just in terms of eating up L2). Surely this can be done more efficiently if done natively.

Hell, I would even take JSFX over KSP.

I understand performance is important but I reject the implication that you can't have both performance and developer convenience. And if the argument is being used as a crutch to avoid moving KSP forward then that's a fallacy.

[EvilDragon]

KSP does have proper functions - albeit without arguments, returns and recursions.


But Lua is not really THAT slow. It's much faster than Python. Still, even JIT compiled (as it is in Falcon and HALion 6), it doesn't match up to KSP...

[tack]

KSP does have proper functions - albeit without arguments, returns and recursions.

Right. Without arguments I don't think you can use the term "proper functions"

Return values, yes, important.

And even in terms of recursion, going back to developer convenience while keeping an eye on performance, why not allow tail recursion?

[EvilDragon]

Thankfully args/returns can be hacked in with a few extra variables, ehehe. SublimeKSP does that nicely. I won't argue that it wouldn't be useful to actually have them implemented. But, pretty much all devs are on SublimeKSP now so... I'd rather NI adds new functionality to KSP, and extend what can be changed via engine parameters (I have a list of things that are sorely missing)...

I don't see how recursions would be useful especially why would you use one in a realtime callback like note on/off or (even worse, because it can be pretty dense) when responding to CCs. Even loops in KSP are limited to a max of around 50k iterations. Probably for good reason.

[tack]

But Lua is not really THAT slow. It's much faster than Python. Still, even JIT compiled (as it is in Falcon and HALion 6), it doesn't match up to KSP...

Yes I think the problem with Lua would be the GC. GC is always a major problem for realtime performance.

Even with Python this can be managed (by avoiding circular references you don't need the GC and can disable it), but of course Python is painfully slow in all other ways.

KSP and even JSFX avoid this problem by not even having the concept of object references. I understand that as soon as you add on the high level conveniences you enter more complex territory in terms of memory management.

Rust actually would be a perfect language for realtime audio. No GC, memory safe, built for concurrency. Maybe too low level for something like Kontakt, though.

[Guy Rowland]

Thanks Mario for all infos, much appreciated. Just picking up on:

Anyways, Jason purely tested loading performance, rather than streaming performance, which is different. It's streaming performance which we're the most interested in - and for that Kontakt is still second to none.

Kontakt still steals a march on Background Loading, this is a big deal, agreed. I'm not so sure it's better in other streaming areas though, is it?

As for loading, I think that's under-appreciated in terms of importance vs streaming. On a good rig, K5 will stream seamlessly at preload buffers, but it might still take a bewilderingly long time to load in the first place regardless of how powerful your CPU and drives are. I'm very interested in modular templates, disabled tracks, track archives etc as a better way forward than huge unwieldily fully-stocked templates. Every operation of loading / enabling / importing is limited by loading speed. Something loading in 1s vs 10s makes the difference between whole ways of working imo. You'd wear a second's delay for every new instrument to load up, but may not with 10s.

[EvilDragon]

I'm not so sure it's better in other streaming areas though, is it?

Versus HALion and especially Falcon, it definitely is. HISE is inching in, though. Kinda hard to properly compare with PLAY and Vienna which are closed systems.

[Lawrence]

Probably because of my ancient system, but I don’t have any real problem with loading times on Mac. Streaming, though, is more of a challenge on CPU in Cubase. The ASIO meter still climbs up there.

[EvilDragon]

Anyone still using those old Kompakt-based libraries, there's a workaround now.

Find NativeAccess.xml and move it out of that folder somewhere. Now RA, EWQLSO, Stormdrum and others will work just fine. However, some of the most recent KP libs needing 5.7.3+ will not be shown in Libraries tab then (like Strummed Acoustic 2, for example).


And of course, once you move out that XML file, don't run NA, because the file gets rebuilt then. You can move the file in/out depending on which libraries you need to use, I guess. This should all be temporary, anyways.

[Guy Rowland]

Thanks Mario - temporary is good!

FWIW 1 have the original East West Stormdrum 1 which is Kompakt / Intakt, and that actually loads ok, although the generic library wallpaper in the library pane has gone and its just blank at the mo.