“Sample cannot be found” message? (within Nuendo) Moderators/ Anyone?

When I try to load an instrument, (Garriton, within Nuendo)…It asks you to save it to a folder, and the instrument then loads fine.

Problem is when I close and try to reopen the project again, I get the…

“Sample cannot be found” message.

I direct it to the folder, but it’s not there…If I try to do a auto-find, Nuendo crashes every time.! Very frustrating.

Has anyone had a similar experience ?

Thanks for any insights, Appreciate it.

 

I have heard of people having this problem. There is a Kontakt update in the works which should solve this problem.

Meanwhile, as a workaround, can you load Kontakt's standalone app, load the patch, then resave it? It should resave its sample path info and thereby hopefully avert your crash.

 

i have the same exact problem, before the 1.5 update i would just hit retry and it would find it but now it cant find any giga sample ive used which is very frustrating...plus my autofind isnt highlighted for some strange reason so i cant search for it like that....


ddas ive tried your workaround and it still cant find the sample do you have any other ideas???this is really holding me back to the point where i think ill have to downgrade till this gets sorted...

Thanks for your help

 

Don't wanna get all cranky and stuff but,

I as well can't find a work around and this problem is thwarting all work.

Much appreciate any more info ddas, christian, and all. I'm sure your all doing your best to help out w/ this.

best, chet

 

Yep, it's a workaround, but unfortunately it also doubles the hard disk usage..:-(

Anyway, if you guys need something to test this problem, try using the latest Cubase SX2, latest Kontakt and Drumkit from hell giga version. This combination seems to be having this problem on almost every project I have.

regards,
sami

 

same problem here weith ALL giga samples. That destroys all work including giga samples created before 1.5.

 

Have you all tried using the one-time sample search function (QuickSearch)?

The workaround I suggested last time should work (loading Kontakt's standalone app, loading the patch in question, then resaving it, thereby recreating its paths). I understand that this is not practical for those of you who are experiencing dozens of "lost" patches.

I will try to find out more information but I admit it's difficult because it's never happened on my system. If any of you have access to crashlogs, please post them.

 

One more thing, could those of you experiencing the problem please detail your systems? Some of you haven't told me whether you're using a Mac or PC, what version of the host you're using, what version of Kontakt you're using, etc. Please let me know this info so we can see if it's a problem unique to either Mac or PC, etc. And as I said before, if you have crashlogs, they would be helpful.

 

My system is Athlon XP 2100+, 512mb, Win2000 service pack3...

I'm running Cubase SX 2.01 and latest Kontakt build (1.5.1).

Anyway, here's a more detailed description of the problem:

If I open a session which uses Gigastudio imported programs (NOT saved as Kontakt patch), Kontakt doesn't find some certain samples inside the .gig file (in the DFH case, it doesn't seem to find certain tom sounds). So the problem must be somewhere in the giga import.

The exact error is:

could not find sample:

d:\instruments\giga\<cDFH.gig>\s\cSonor Tom 5 R07

find it automatically or locate it manually?

The session was created using Kontakt 1.2.1 and it worked fine on that build. After switching to 1.5.1 I've not been able to open the project anymore without pressing "abort loading" and by re-loading all the instruments inside Kontakt. The "auto find" button is not enabled at all, and browsing doesn't help much because Kontakt tries to search for .wav files which are ofcourse "inside" the .gig file.

regards,
sami

 

I'm on Mac Duel 867 ...osx/ 10.2.6
Nuendo

 

I see an inherent problem there, Sami: You're not saving the translated GIG file as an NKI file. I used to have problems with Kontakt not being able to "re-rip" Soundfonts and Gigas (no .WAV extension is recorded, which I see on your error message) - this never happens to me anymore because I always save the Giga as an NKI file. I would strongly suggest you try that first (I know it uses more space, but if you like the samples so much, it's probably worth permanently storing, no?). Why not save it instead of having to import it every time? It'll load more quickly too.

Just a suggestion.

 

hi b.duffy,

Can you (or anyone) fill me on how to save the giga file as a nki file ? ...I don't remember having that option.

Thanks, c

 

My friend, it's quite simple: LOAD/SAVE, SAVE INSTRUMENT. Once you save something from Kontakt (deafault, saving the samples to a local folder) it becomes Kontakt-format. That's it!

I don't remember if the manual was clear on this or not - I can't even remember off the top of my head if Kontakt 1.0 imported Giga?? I think it did. You might want to review your manual.

 

Some info from using MacOS9.2/Kontakt1.2.0.020 and PC W98 SE/Kontakt1.2.0.020 (*.wav audio)

From PC, after pasting keymap/zones from one patch into another patch, that was opened from a different dir but finally saved in same dir as the audio - the patch opens fine on PC.

If the above patch is to be opened from a Mac, one have to tell Kontakt where the audio resides. It's not enough to select the right dir, you have to select the actual audio file. The "use same dir for.." works fine though.

If the above patch then is saved from within the Mac. It then opens fine from the mac but same thing happens when it's opened from PC. One will again have to help Kontakt find the audio.

All this is with "relative" paths.


One solution to the *opens-in-pc-but-not-mac* is to from within pc

1. Rename the *.wav files for the patch you want to *fix*.
2. From Kontakt, open the patch. (It's going to ask for the missing audio)
3. Tell kontakt what *.wav files you want to use for each zone
4. Save (Now it works from Mac and PC)

I don't know if same "fix" works, performed from a Mac. Also, perhaps these things are all fine in later versions.

/h