Request - please make nki's backwards-compatible

[beely]

The term is "forward compatibilty" not backwards, meaning that you can play a preset made with a younger version on an older version of any given software, confusing I know...

Not meaning to be a smartass, but i dont think this can be right. Otherwise it would be very strange usage of terms that have a clearly defined meaning. Let me explain:

If i made an NKI today, and made it so that it works in versions of Kontakt that will be released in the future, i would have made the NKI forward compatible because the compatibility would be with Kontakt versions that are yet to come. (Future = Forward)

If on the other hand i make an NKI today, and make it so that it still works with versions of Kontakt released in the past, i would make the NKI backward compatible because the compatibility would be with Kontakt versions that are older than the NKI itself. (Past = Backward)

If the accepted meaning is really the other way around, humanity is in trouble.

The compatibility "viewpoint" is always with the software version, not the the file. Common mistake, as people often choose the viewpoint of the most convenient thing they are discussing (the actual file).

It's simple.

If a current program (say, V5.x) can load "old" files (V1.x - V4.x), it has backwards compatibility with old file format versions.

If an old program version (say V2.x) can still load files from the current version (V5.x), then the V2.x software has *forwards compatibility* with those files.

(Or expressed another way: those current files have forwards compatibilty with V2.x onwards)

When the OP wants Kontakt 2 to open Kontakt 5 files, he wants forward compatibility.

This is often very hard with software, as it requires predicting the future, and guaranteeing that your file format will never radically change, or new features cause conflicts with old features, or gets increasingly hard to support via translation. However, sometimes partial forward compatibility is offered, in the case of something like Photoshop, which can usually load newer files, with the proviso that not all features may be supported and so there is no guarantee everything will be intact. As least in the Photoshop file format, it contains the raw pixel data, so if some newer features don't translate, you still have the raw pixel data which should be correct.

Life runs sometimes contradictory to common expectation, that's where education and research comes in handy!

[metamorphosis]

The term is backwards compatibility, when applied to nki releases, not to the software engine - I build software, I already understand the concepts here.
ie. If you release something, provide it in K5 as well as K3 or K2 formats.
Otherwise you're forcing the customer to not just buy your product, but another product as well.
Or just use an open standard like sfz which doesn't need to change because it's not attempting to push 'new features' to make money (this is where the engine comes into effect - I hesitate to call it 'future compatibility', because really it's just money-making strategies).

[ENV1]

Like I said earlier - usually the term backward/forward compatible is used for the progream, ie. Kontakt. The meanings of backward and forward compatible would flip if you were to atypically apply the terms to the NKIs rather than to Kontakt.

Exactly. And the OP clearly said NKIs. His use of the term backward was therefore correct from his viewpoint. The fact that it is the other way around when you are talking about the application remains untouched.

right, but nobody said that .nki are not forward-compatible.
you can't make them backward-compatible thats what the thread is all about.

I realize these things.

What i said was with regards to the forward/backward thing only.

[murnau]

@ENV1 you are right as well. if you see it from the library viewpoint (like OP) then it's right but it's beeing already said that you better have to see it from the software viewpoint. kontakt itself is backward-compatible but the libraries not and that makes the confusion. it makes no sense to ask for "backward-compatibilty" while keeping the host-software completely out where in the end you have to load/save everything.

when kontakt is backward-compatible then the libraries only can be forward-compatible. (how it is atm)
when kontakt would be forward-compatible then the libraries only can be backward-compatible. (that is not)

OP had better asked for forward-compatibilty of his kontakt version but then towards NI instead.

[idfpower]

Geez...you make such a simple topic sound so complicated

The real issue is this: in order to be able to use a new library with an older/earlier version of Kontakt there should be an option when creating that said library that would allow the creator to decide with what specific versions of Kontakt would that library be compatible with. I'm not a Kontakt library creator so I don't know whether such an option already is available or not, but to me this seems to be the solution.

Now looking from a Kontakt library creator's perspective, I wonder if it's worth trading giving up on the latest options offered by the newest Kontakt version in favour of attracting more customers by making the library compatible with older K versions...

[ENV1]

OP had better asked for forward-compatibilty of his kontakt version but then towards NI instead.

Well the OP must have thought that something can be done to make libs created with newer versions load into older versions. I can understand that, if i was a samples guy and running an older version of a sampler i would probably want that too. But im not a samples guy and i have no experience with Kontakt other than the occasional fooling around on the computers of friends. So i have no idea whether or not this would be a realistic desire. Im simply not qualified to comment on that part.

[whyterabbyt]

The real issue is this: in order to be able to use a new library with an older/earlier version of Kontakt there should be an option when creating that said library that would allow the creator to decide with what specific versions of Kontakt would that library be compatible. I'm not a Kontakt library creator so I don't know whether such an option already is available or not, but to me this seems to be the solution.

I could be wrong, but I dont think there is that option. I suspect you'd have to create in the older version of Kontakt, then import that into the newer one and edit it.

Now looking from a Kontakt library creator's perspective, I wonder if it's worth trading giving up on the latest options offered by the newest Kontakt version in favour of attracting more customers by making the library compatible with older K versions...

I'd suspect not. Or at least not that far back. When K5 came out, most libraries were K4-and-up for a while yet, but nothing 'new' that was pitched as a Kontakt instrument(*) seemed to be older than K4.

(*) There's more to modern Kontakt libraries than the samples these days; most are heavily reliant on scripting and that's not necessarily that far backwards-compatible. I certainly see very little K3 stuff with the sophisticated work of K4 and K5 libraries. I dont doubt many library developers would see no point in releasing the sample sets as minimal K2/K3 (or, moreso, sfz) when what defines them as 'their' instrument releases is the UI/scripting work.

edit : just for the record K2 dates to 2005, K3 to 2007, K4 to 2009 and K5 to 2011. So even the K4 version of the NKI format is 5 years old. What the OP is asking for is compatibility with 7- and 9- year-old versions.

[murnau]

Geez...you make such a simple topic sound so complicated

[idfpower]

I could be wrong, but I dont think there is that option. I suspect you'd have to create in the older version of Kontakt, then import that into the newer one and edit it.

That's what I've heard as well, but since I can't be 100% sure I prefer not to consider it as fact

(*) There's more to modern Kontakt libraries than the samples these days; most are heavily reliant on scripting and that's not necessarily that far backwards-compatible.

Yeah, I think that's the main issue - compatibility-wise. That's why I don't think "fixing" the nki files would do the trick...

[whyterabbyt]

I could be wrong, but I dont think there is that option. I suspect you'd have to create in the older version of Kontakt, then import that into the newer one and edit it.

That's what I've heard as well, but since I can't be 100% sure I prefer not to consider it as fact

well, basically, I cant check my own copy right now, but I have checked the K5 reference guide for what it says about saving NKI files, and cant find any reference within that to saving in an older version of the format.

[mfb]

Its not just scripting, Kontakt has added new filters and effects and even sample playback modes as it goes, so if a Kontakt 5 patch uses, say, the "time machine pro" playback mode and an "adaptive resonance filter", both of which were introduced in K5, then how could you open such a NKI in any earlier version of Kontakt? That is the reason why Kontakt is not forward compatible, or why NKIs are not backward compatible.

There is no option in K5 to save e.g., a K3 NKI. In principle, *if* the particular patch did not use any of the new features, this would be possible. However, its probably not worth NI's time to implement it. They have already got the money for any old version of Kontakt you have, so increasing the usefulness of old versions does not make them any money. Making new versions desirable - all those juicy new sounds for K5!! - is in their interests, since it will make people fork over money for the new version.

[Zombie Queen]

The real issue is this: in order to be able to use a new library with an older/earlier version of Kontakt there should be an option when creating that said library that would allow the creator to decide with what specific versions of Kontakt would that library be compatible. I'm not a Kontakt library creator so I don't know whether such an option already is available or not, but to me this seems to be the solution.

There is no such option, I reckon it's both too complicated to be worth it and not in NI best interest. Point is NI want everyone to update to latest version, it's understandable. From developer's point of view you would have to start developing, the instrument say in Kontakt 2, save and then add options available in next version and so on, it's a mess and you would need to have all Kontakt's versions, considering that most of users upgrade to latest, it's not worth it. I sympathize with OP, as I decided to skip at least version 5, so I can't use any of NI libraries, as they upgrade everything and do not offer downloads of earlier versions. It's somewhat disappointing, but that's the way it is.
In many cases scripting is only used to bring some controls up-front, and those instruments could be as well compatible with K2 (if you don't care about custom graphics), not to mention sfz. But there are instruments that would not be possible to do in earlier versions of Kontakt, not to mention sfz.
Long story short, the answer is no.

[whyterabbyt]

Its not just scripting, Kontakt has added new filters and effects and even sample playback modes as it goes, so if a Kontakt 5 patch uses, say, the "time machine pro" playback mode and an "adaptive resonance filter", both of which were introduced in K5, then how could you open such a NKI in any earlier version of Kontakt?

its entirely possible to structure exporting an older-version file such that unsupported features 'fall through' to compatible versions, ie 'time machine pro' be exported as a 'time machine 2' mode, adaptive resonance filter gets exported as a basic lowpass. this is common in all sorts of software.
guaranteeing the same behaviour is impossible, but exporting a working older-format NKI, technically, wouldnt be.

[mfb]

Sure - that could be done, but it would be messy as NKIs would sound different in different versions of Kontakt, possibly quite different. I agree it would be nice to have this ability, but it would be a bit of a kluge. Its anyway not really in NI's interest to get this working. It would be a mess for sample developers too since they'd have to have parallel versions, and then they don't want people whining because the newest super-duper sample library sounds like crap if you open it in K2.

[idfpower]

I reckon it's both too complicated to be worth it and not in NI best interest.

Yeah, that's what I'm thinking as well ('cause otherwise it would have been done already).