# Kontakt 4.2 - save_array question



## gregjazz (Dec 27, 2010)

Should be in the instrument options.


----------



## polypx (Dec 27, 2010)

Ah ha! That's new too! 

Thanks Greg.


----------



## polypx (Dec 27, 2010)

Hmm. This doesn't seem to work as I expected. In mode 1, there can only be one array saved/loaded into any scripted array. (I was hoping to use this to load large arrays, somewhat like presets.)

Now I'm not sure what it's purpose is. What is the advantage of having the array on disk over having it in the script?


----------



## Dynamitec (Dec 28, 2010)

Hi Polypx,

I'm not sure what you problem is with save_array. Why do you want to use mode 1?

I recently used save_array and load_array to build a preset system. It works perfectly fine with mode 0. If you use mode 1 with resource container and the data folder the user won't be able to access the saved array later (e.g. to share presets). 

But anyway, the benefit of having the array on disk over having it in the script are:
- a lot of instruments can share one array (e.g. with default values)
- large arrays added a lot of loading time to the instrument (which sounds unbelivable but was the case) when used as persistent variables.


----------



## polypx (Dec 28, 2010)

> - a lot of instruments can share one array (e.g. with default values)
> - large arrays added a lot of loading time to the instrument (which sounds unbelivable but was the case) when used as persistent variables.



Hi Ben,

Good points. I hadn't thought of sharing between instruments, but that makes a lot of sense. I was definitely thinking of using it to store multiple large arrays (as presets).

The reason I was trying to use mode 1 was to avoid the dialogue window, and just build a menu that accessed various stored arrays directly (inside the resource). If we use a dialogue window, the user has to know where the presets are stored, and what they're called, etc.  However, my problem with mode 1 is that I can't have more than one "preset" per array, since it by default takes the name of that array, and overwrites it on save.

Maybe I'm missing something here though. I only began looking at 4.2 today, so may have overlooked an obvious technique. 

Anyway, thanks for the feedback, it's very helpful. If you have any other suggestions, it'd be much appreciated.

cheers
Dan


----------



## EvilDragon (Dec 28, 2010)

Well then, you'd have one array per preset, to store multiple presets, right?


----------



## polypx (Dec 28, 2010)

Hey Mario, 

Sure, but if I have one array per preset, there's no advantage to storing it on disk, since I need an array of that size for every preset. I might as well fill it up in KSP.

(except for the sharing idea Ben suggested)

I know I'm not a genius, but something seems wrong. Why can't I use mode 1 and load a variety of arrays into the same preset? That's what I want to do.

Dumber, and dumberer,

Dan.


----------



## kotori (Dec 28, 2010)

Hey Dan,

I had the same thoughts as you and let NI know about this before the public beta was released, but apparently they prioritized API simplicity over flexibility in this particular case, and I guess we'll have to live with that. I don't know why they did this since a file name argument would be natural (that Kontakt would pick the directory automatically in the non-dialog case is however probably good as it is).

Btw. regarding the speed difference that Benjamin mentioned I think the situation is the same, loading is terribly slow in both cases, but by using load_array one may sometimes be able to defer some loading until later meaning that the user will perceive it as being faster. 

Nils


----------



## polypx (Dec 28, 2010)

Nils, 

Thanks for the confirmation.

You're right, a file name would have been simple enough (and we already use that for IRs, pictures, etc.)

By the way, it looks like we can include pictures in the Resources folder now, is that correct? This removes the need for a KPlayer build or installer for custom graphics, if I understand correctly?

cheers
Dan


----------



## EvilDragon (Dec 28, 2010)

Yep, we can include pictures now, no need for installers!


----------



## polypx (Dec 28, 2010)

Nice.

Still can't 'Add Library' though ?


----------



## EvilDragon (Dec 28, 2010)

Nope. Legally speaking, it's still reserved only for KP libraries.


Then again, when there's a will, there is a way. o-[][]-o


----------



## polypx (Dec 28, 2010)

Mario, do you have the will and the way?


----------



## EvilDragon (Dec 29, 2010)

Of course!


----------



## polypx (Dec 29, 2010)

But you're not telling?


----------



## EvilDragon (Dec 29, 2010)

Not out loud. :lol:


----------



## Lindon (Jan 5, 2011)

Wha? "save pictures"? I'm not using 4.2 yet, still ploughing thru preset development hell for the GM's, do I not have to save all my button graphics in c:/blah-de-blah/my Documents/ Native Instruments/Kontakt 4/pictures/whatever anymore?

Where would I put them?

--- yes yes I could go install 4.2 and look in the manual prob. , but I'm old, cranky and busy...(ish)...and I'm worried something might break, which would be "V. Bad" right now... 

If its true this might be worth the risk as it would make my life a LOT easier...


----------



## polypx (Jan 5, 2011)

You can install 4.2 without losing 4.1, while it's in beta. 

As Greg mentioned above, there is now a Resources folder, which is very handy for keeping scripts, IRs, pictures and wallpapers, as well as the arrays that I started this thread with. 

So yes, you no longer will need to put your button graphics ins c:/blah blah 

cheers
Dan


----------



## d_v (Jan 10, 2011)

Hey Dan and Nils,

You shouldn't think of the save/load_array commands as anything more than the means to write arrays to disk. Yes, you can use them as a tool to implement your own preset system, but it's up to you to organize your data in standard KSP arrays, and there are many ways to do that. On this note, nothing stops you from invoking a save/load_array command more than once in a single callback, meaning that you can split up your data in multiple arrays if you're going with the "mode 1" approach (you can write/read multiple arrays by just clicking on a single ui_button, for example).

The greatest benefit of implementing any kind of settings/preset system using the save/load_array commands is the ability to keep this system independent of the NKI file (which wouldn't be the case if you used persistent arrays). Two quick examples of why this can actually be beneficial: 
* you can access your preset/settings system through multiple NKIs (as mentioned by Dynamitec), meaning (among other things) that you can have changes made using one NKI applied to a whole library.
* you can update the NKIs (bug-fixes?) without overwriting user settings/presets.

In addition, having the file names mirroring the array names and thus removing an additional layer of keeping track of your data structures seems absolutely fine to me. It just means that the scripter will have to design his data storage format on the KSP level, which is something that doesn't pose any limits as far as I can tell. A limit that is definitely still there is the fact that string arrays are not supported, but that's a whole different discussion.

Just my two cents! 
d.


----------

