Kontakt File Reading, Renaming During Conversion, Changed Parameters in MPC Export

[PhilipStolz]

Kontakt File Reading: Enhanced the software by a detector for Native Instruments Kontakt files. Currently the software can read older nkm and nki files which are a sort of zipped xml files. Current import supports K2_Programs and NiSS_Programs. Renaming During Conversion As I'm using a specific naming convention in my sample program collection, I built-in a csv-file based renaming function for programs that can optionally be used (further solutions could include regular-expression-based renaming or other more advanced ways for renaming). Changed Parameters in MPC Export The computation of envelope times was corrected (max. duration is still 30s but the function is exponential as I empirically figured out by measuring the resulting durations in the MPC software.) The logic for deciding the trigger mode was changed: To support drum kits as one shots as well as kit with phrases that have a sustain value in their envelope as "note on".

The current function was validated with the Kontakt meta files provided with the Zero G "Funky Elements" sample library and a couple of other NiSS and K2-type Kontakt programs or banks.

[git-moss]

Wow, this is impressive! Will need to find some time to look into it. Many thanks!

[git-moss]

Hi, you might have noticed that I went through the NKI detector over the weekend (please check with your files). By doing so I was trying to find more info about the format and started to look into it a bit myself. I guess you got your info from here as well: http://www.linuxsampler.org/nkitool/

Especially, finding the ZLIB start needs to be improved and there are also some other formats which should be supported like the monolith with the WAV files in it. I tried to gather some files from the deeps of my harddrives and have a nice list of different versions. Will try to start to document the format a bit. If you have any additional info this would be very helpful :-) Would be great if the format would be understood enough to write it as well.

[PhilipStolz]

Right, I also got my first idea from the nkitool and then just started reverse engineering the nki files I had. As soon as I understood how the KONTAKT app works, the meaning of the parameters in the nki files was pretty clear. But I didn't have a look at any of the nki files with baked-in samples. I appreciate your effort and I'm looking forward to being able to also convert some of the newer nki files eventually.

[git-moss]

I documented what I could find out so far and sent you a link in case you want to look into it as well.

[PhilipStolz]

Interesting, just had a look at your documentation. According to what you figured out, I only had KONTAKT files of version 1 and 2. The xml content of v1 and v2 differs only a little bit in structure and in some cases in tag names but it's still pretty similar. According to your example about version 4, the xml content seems to have changed dramatically. For v1 and v2 xml, I could try to create a sort of tabular overview showing which tag in one version corresponds to which one in the other version.

[git-moss]

I started to do a bit of testing and ran into an issue with the tune calculation: sampleMetadata.setTune (12.0d Math.log (zoneTune groupTune progTune) / Math.log (2)); This gives e.g. for log(1 0 0) = "-Infinity" in Java. Is the meaning of "1" = 12 cent and "0" = 0 cent? So, could this be simply: tune = (12.0 (zoneTune + groupTune + progTune)) / 100.0 ? Note that tune needs to be in the range of [-1,1] which represents [-100,100] cents.

[PhilipStolz]

Just had a look at some Version 2 patches. It seems that the progTune, groupTune and zoneTune parameters in the xml structure seem to be coefficients for the playback speed. None of them is 0. I found some that were pitched down by 12 semitones which corresponded to a parameter of 0.5. Let me explain how I came to my computation of the tune parameter: As zones are part of groups which are part of programs we would have to multiply all the coefficients to get the final playback speed. If we then want to translate the whole thing back to semitones we would have to resolve the following: progTune groupTune zoneTune = 2^(semitones/12) <=> log2(progTune groupTune zoneTune) = semitones/12 <=> 12 log2(progTune groupTune zoneTune) = semitones <=> 12 log(progTune groupTune zoneTune) / log(2) = semitones <=> 12 log(progTune groupTune zoneTune) / log(2) 100 = cents

Do you have NKI patches with tune values of zero? Maybe they switched from storing coefficients to semitones or cents in one of the versions.

You wrote: "? Note that tune needs to be in the range of [-1,1] which represents [-100,100] cents." OK, you're right this was what you wrote for the setTune method of the ISampleMetadata interface. Does it make sense? It would mean that you cannot pitch up or down a sample by more than a semitone with this parameter. Is there any other way to pitch up or down a sample in your intermediate format?

[git-moss]

I created an issue in the other repo. Please have a look. Regarding your question: Calling e.g. setTune(0.24) means it is pitched up by 2 octaves. So you need to devide a cent value by 100.