Heres My Problem With Kontakt2

ICK!!

I see your problem but honestly had forgotten about how Steinberg manages it's Tracks.
Now I remember why I moved to Sonar

Actually one of several reasons , but that is another thread....
In Sonar it is as simple as cloning the track , archiving the original , then removing/inserting the new plugin. Done. Nothing lost.



CH

 

Bit of a kludge, but you could insert any FX/EQ on an SX group channel and route your instance of Kontakt 1.5 there... Then, when you want to replace it with Kontakt 2, you only need to route the new instance to the same group.

 

Or you can save the Multi from K1 (with Patch only, to save space), Save the Kontakt VST Mixer settings, unload K1, load K2, load Multi, load Mixer settings.

I'm not sure what K2 will do with the Stereo/Mono settings, I understand K2 has 32 stereo-only channels. My enthusiasm for K2 is waning a bit...the posts are taking a turn for the worse in the last few days!

 

bump can we get a response from the ni team or what??? i dont know about you guys but im not planning on having different versions of different songs for different samplers...

no other audio software company does this kind of upgrading where they rename the original plugs and ruin peoples old projects...


NI A SOLUTION PLEASe???

 

I have now converted two projects from Kontakt 1.5 to 2.0. Each time I saved the existing K1.5 instances as multis. Then I unloaded the K1.5 instance, loaded the new K2.0 and loaded the saved multi. Everything came in just as it was in K1.5, same midi and audio references in Cubase SX 3.0.2. Then I went on to the next instance of K1.5 and repeated the procedure until all the instances of K1.5 were replaced.

No problems with either project. One thing that I believe you must do is convert one instance of K1.5 to K2.0 at a time; do not try to unload all instances and then load all new instanced at once.

Hope this helps,

Dave

 

This is a host topic

Honestly, if the plugins were named the same and replaced, NI would be putting some work in jeopardy. Giving you the choice is much more important than forcing an all or none use of the plugin.

I think the real issue you have brought up is not even with NI; its with host recording software.

Our song documents contain more than notes. They contain higher level objects than the instruments themselves that include all the routing involved to make something sound and behave 'just so'. Since we use these plugins so much, they become as integral to the composition as your fundament, counterpoint and arrangement strategies.

I do want to say this is a great topic and an issue at large for everyone who uses software instruments or anything above the level of notes, and who insist on: backwards compatibility and total recall.

Host software is still evolving however and accomodating such heavy reliance on plugins is something that will come about. For example it would appear that you would prefer to edit the song document not in 'graphic' or interface mode, but in some other mode that allows for searching song structure and things like GROUP REPLACE. The song document format of each host is dark, for business and proprietary reasons. Instead of renaming the plugin, it makes more sense to edit the song document in a text editor and everywhere the pattern 'kontakt.dll' appears, replace with 'kontakt2.dll'. The references to what content to load into the process should remain the same. Your benefits in doing so would not merely be limited to the choices of new effects like convolution reverb, but a MUCH more robust sampling engine, use of multiple processors and also improved DFD.

Perhaps a host will implement such new plugin interface features that will aid not only in upgrading, but in keeping your catalog of works compatible with new technology.

When considering what host software you commit your works to, you should give thought to the serious investment over years you make in that single choice. Most software I know of is only concerned with very short deadlines, and is shaped overall by the transient 3-4 minute musical commodity. Will the host company even be around in five years without being absorbed, merged, and regurgitated through some absurd technological phagocytosis? One of the puzzles of concerted evolution is how multiple copies of a gene co-evolve even if they do not appear on the same chromosome or even in the same locus. There are few music technology companies that can still stand on, and hold their own. NI is one of them.

Also, don't expect an official response...this was the best I could do in my free time, and we are all very busy.

I think the suggestion to save your K1 multis and reload is the best one. If that is too much hassle for you, then think about getting back to notes. Maybe some day a host will evolve that can help you better manage these little parasites upon which you so depend.

 

Seriously, what's the problem with old songs made with K1.x? They will still just load fine.
K2 is a new instrument and treated as such - and that's all there is about.
It's just the same as with every old plugin: You need to keep it until you don't plan to load any older songs using it anymore.

Of course, in this case it *could* have been done in a different way as well - K2 entirely replacing K1 that is.

But then, if you were developing sampler patches, you wouldn't be able to satisfy K1 owners anymore (as K2 patches aren't readable by K1).
So, keeping both intact will actually offer everything. Old songs will load fine but you could still use K1, should you for instance be collaborating with someone not having updated yet.

 

But what about your mixer settings? This is my biggest concern! Saving and reloading multis is a minor pain, but when you remove K1.5, it will remove all the VST Channels, Inserts, Sends and Routing. What I'm wondering, Dave, is if how you got around that?

 

That's the way it works with DXi's because they are identified by some long random-ish unique identifier emitted by the Microsoft tool chain. But VSTi's are identified by their path/file name. If you do the default thing of letting them all land in C:\Program Files\Steinberg\VSTinstruments, then giving Kontakt 2 the same file name as Kontakt 1 means that one ends up replacing the other. I don't know about Cubase, but the VST wrappers I use with Sonar do allow me to have VSTi's in different directories (folders), and to edit the name that's displayed in the plugin selection windows. It may be that all that's really necessary here is to *not* accept the defaults when installing Kontakt 2 as a plugin, and to make sure that it goes somewhere like ..\VSTinstruments\Kontakt2. If your tools don't allow you to edit the displayed names, and they both come out as "Kontakt" (as opposed to "Kontakt" and "Kontakt 2"), I suppose one could just get used to knowing which one is first on the menu list. But as someone else observed, this is more a host problem, and YMMV.

 

I actually still don't see the problem.
I just keep K1.x and K2.x installed parallely. No big deal at all.

And regarding the exchange of a VSTi in SX while keeping the channel settings intact, that's got nothing to do with Kontakt or NI or whatever but simply with the fact that SX is handling VSTis rather lame-ish.
In Logic I just exchange the instrument and the rest of my channel settings will stay intact.

 

Unless NI has crippled their installer in the last year, that option already exists. You can override the default VSTi installation directory and put it somewhere off to the side (or in a folder just below).

 

I think with Kontakt 1.x you risk application errors if you try to install an update seperately, I know I got some when I installed an update to a different directory by mistake. The main thing is that 1.x updates will always install a dll called, "kontakt.dll", whereas K2 installs one called, "Kontakt2.dll".

Personally, I like how SX completely unloads the VSTi and its channels. I just don't like it when an update is not backwards-compatible. Still, an SX-User should be able to re-load the VST Mixer settings. Just a pain in the ass.

 

Sacha,

In Kontakt153 you could configure so that in Cubase SX3, you had only 1 stereo output showing up if that's what you wanted (or 4 stereo or 16 stereos or whetever you choose 1-16).

Kontakt2 does NOT have the possiblity. That is bad. Not good.

A clear step backwards for the Cubase SX3 user. Not a step forward.

Why *remove* such a basic and necessary function?

=============

Do you understand that Kontakt153 users get really dissapointed when they find that the must *hide* 180 audio channels in Cubase SX..... click click click click click click click click...

(12 instances and 15 outs that I don't want for each)

All these extra channels are consuming ram/cpu by being live establiches audio paths. That's bad.

=============

Do you think having this configuration possiblity removed from Kontakt is good or do you think it is bad Sacha?

Lars