# Graphics directories...



## Lindon (Jun 19, 2012)

I'm thinking of doing some non make_perfview scripts, so I'll need them to work with a range of user config.s and where they are not pointing at my resource file. Where is everyone putting their graphic images (for controls etc.) these days?


----------



## mk282 (Jun 19, 2012)

RCs are where it's at as far as I'm concerned. Before that, everything went into user documents folder. Which is, on Windows (7 here):

C:\Users\<username>\Documents\Native Instruments\Kontakt 4 <or 5>\Pictures\


----------



## Lindon (Jun 20, 2012)

Hmm, yeah RC's work for me too (as you know) but I'm thinking of releasing a bunch of scripts in a kind of Sonicouture Scriptorium product. 

It'd all work a fair bit better if I could use (and reuse) lots of the graphic work I've done on the GM products (versions of these would get included), these are currently on /Resources/Pictures and pointed to using an RC, BUT of course (unless I'm much mistaken - always possible) the RC is linked to and by a Kontakt .nki instance, and I wanted to have the scripts usable across the end users own instrument sets...so RC's are out. 

If nothing else I'll need to do "versions" for Kontakt 4/5 on Mac and on PC unless I can find some common place to get the user to put my Pictures directory on install.

Maybe I could use $GET_FOLDER_FACTORY_DIR in some way...


----------



## mk282 (Jun 20, 2012)

Nope, $GET_FOLDER_FACTORY_DIR won't work.


If you load a graphic just by using, say "picture" as attribute for $CONTROL_PAR_PICTURE, the folder I typed above is the first one Kontakt will look into for graphics. So, a separate folder for K4 and a separate one for K5.

I suggest you make an installer that will put graphics in that folder (I also recommend to create subfolders in that Pictures folder, too), then just assign graphics to controls as you usually would if you were using RCs. So this installer should install to two folders in case both are installed in the system.


Also, the path is SLIGHTLY different for Win XP.


C:\Documents And Settings\<username>\...the rest is the same.


----------



## Lindon (Jun 20, 2012)

Hmmm, looks like its back to building an installer then that accounts for Kontakt 4 & 5 and Windows XP, Vista and 7....and that images go in a separate directory structure to scripts....

Any one any idea where on the MAC the images go? and if the scripts go in the same spot as PC?


----------



## polypx (Jun 20, 2012)

On the Mac the safest place is Library/Application Support/Native Instruments/Kontakt 5/pictures... and best if you make your own subfolder there.


----------



## Big Bob (Jun 20, 2012)

For general usage scripts that employ custom graphics, there are some complications that arise when distributing the graphics as a compressed .nkr file. 

When the script(s) are installed in an instrument, the user must 'point' the instrument to the .nkr file. This in itself is not much of a problem because the script author can provide some fairly simple instructions to the user to help him accomplish this. The complication arises when the user wants to use one or more additional scripts that also use custom graphics. If another script also has its graphics in a .nkr file, the instrument can only be 'pointed' to one of the two.

There are a number of ways to work around this that I can see but they all require either that the two script authors get together and create a composite .nkr or, as kb123 suggested in his post, we have to distribute the uncompressed png files and provide some means for the end user to access both sets of custom graphics with the same instrument.

In order for the end user to make a composite .nkr file, both script authors will have to distribute their unpacked graphics files. However, I think there is another way to provide access to multiple sets of custom graphics when only one of the authors provides unpacked png files.

To illustrate what I'm thinking, suppose we have two scripts (distributed as .nkp files) named A and B. Let's further assume that script A is distributed with only a packed .nkr file so the user must point his instrument to that .nkr. The Author of script B distributes his script with both a packed .nkr file and a folder named *Resources* containing a sub-folder named *pictures* which contains all the unpacked png and corresponding txt files for script B. 

Now end users that only install script B can simply use the .nkr and point their instrument to it. Those users that want to run both script A and script B, can merely copy the Resources folder and its contents to a position 'alongside' script A's .nkr file. If there is already a *Resources* folder there, then the user can simply copy the pictures folder for script B and, if there is already a *Resources/pictures *folder set in place, then the user need merely copy the contents of script B's picture folder.

After doing this, I think the instrument will read script A's graphics from script A's .nkr and script B's graphics from the Resources folder. Thus, making both sets available to the same instrument. Of course if the user is trying to use A, B, and C scripts and only B provides the 'source' graphics, the instrument can only be pointed to either A or C but not both. However, this is no shortcoming on the part of Author B because the user cannot use A and C together anyway (whether or not he installs B).

Another advantage of doing it this way is that I think it will work for both PC and MAC (and K4/K5) and avoid having to distribute two or more versions of the script's .nkp files. *MAC users, is this a valid assumption on my part?*

Maybe someone can suggest a better way to handle this problem? Especially if the above doesn't actually work the way I think it will :lol: 

Rejoice,

Bob


----------



## ScoringFilm (Jun 21, 2012)

If you are dictating the directory in the script itself use forward slashes (/) as this will work with Windows or Mac.

*Windows 7 onwards:*
C:/Users/%username%/Documents/Native Instruments/Kontakt ***/Pictures/

*Win XP:*
C:/Documents And Settings/%username%/My Documents/Native Instruments/Kontakt ***/Pictures/

*Mac:*
StartVolume/Users/%username%/Documents/Native Instruments/Kontakt ***/Pictures/

** = Kontakt version (4 or 5)*

Justin


----------



## Lindon (Jun 21, 2012)

Bob,

As ever a smart post. 

Problem I see is here I am trying to provide a set of somewhat generalised scripts to use with *any* of an end users instruments (I am "B" in your example). So I could employ the solution you suggest, and the end user would need to copy my images into each resource folder for each instrument they wished to uses my scripts with...a bit of an ask really. Plus this only works for instruments that use a resource container, those that dont still have the issue of where to put images...

It'd be nice if NI had thought this through a bit more and allowed each script to have its own local sub-directory to hold images, so installing the script (in the scripts folder) would also copy its images in for all instruments to use....but they didnt. 

So it looks like, when I get around to it, I will have to code an installer that places images in different folders for K5 and K4, on a range of different operating systems. SO as Justin points out 6 different places....

Ineligant doesn't seem to quite cover it.


----------



## Big Bob (Jun 21, 2012)

> Plus this only works for instruments that use a resource container, those that dont still have the issue of where to put images...



Hi Lindon,

Actually, when the instrument *doesn't* already use a .nkr, the situation is far simpler. All the user has to do is put your .nkr file anywhere he desires and then point the instrument to it (simple to do in Instrument Options). The problem I cited only arises when the instrument is already using a .nkr file *and there is no Resource folder*. In other words, when script A was installed with all its graphics in the .nkr.

When the existing .nki uses a .nkr, it will already be pointed to it. All you have to do then is instruct the user to put your supplied Resources folder (and its contents) alongside the existing .nkr file. If the existing instrument was installed with the Resources folder still intact, then the user needs to add your additional pngs to the pictures folder (under his existing Resources folder). This is perhaps the messiest situation.

Of course there is also the problem that many scripts will not work in concert with each other and this has little to do with custom graphics. However, assuming that a given pair of scripts will work together harmoniously, then I think my suggestion will require the least complicated instructions overall.

I'm not sure I really follow in what way using a custom installer would make this process any easier. Could you give me an example of the steps that the end user would have to perform (and what questions he would have to answer) in order to install your scripts into an existing .nki if you wrote some 'magic installer''?

As I see it, the best way NI could make this easier would be to make the graphics part of the .nkp files themselves. No matter what else, the end user always has to know how to load your scripts as nkp files. If just loading the .nkp would also load and 'setup' the graphics that it requires it would be nice. But, I think NI is probably more concerned with making .nki s work like that than they are about add-on scripts.

Rejoice,

Bob


----------



## Lindon (Jun 21, 2012)

Bob,

OK so lets assume we build the installer with NSIS - the open source free installer builder thingy...

I have a constant there called $DOCUMENTS which points at the users documents (or my documents) folder - this I think deals with the different OS issues on Windows right away. I code something to look for a sub-directory structure called: 

$DOCUMENTS/Native Instruments/Kontakt 4/Pictures/

and if found I create an additional structure called:

/myCompanyName/myProductName/

and put the images there, I repeat for: 

$DOCUMENTS/Native Instruments/Kontakt 5/Pictures/

Where neither are found ...well then trouble is a-brewing 'cause my scripts wont work, and perhaps they havent even got Kontakt installed properly...

Next I go looking for the install directory of Kontakt 4 (if the structure above is found) - I can probably get this out of the registry..not sure..and put my actual scripts in the Scripts directory structure there..again using /myCompanyName/ as a sub-directory

repeat for Kontakt 5

If I cant find where Kontakt 4 or 5 are installed I ask the user where the scripts directory is... (this then is the only question I *might* have to ask...)


This works in such a way that all the scripts are in the "right" spot and all the images are in the "right" spot....

...for a windows install. Mac is another issue again...I havent even got a Mac....

It's just a pain to have to code this....


----------



## Big Bob (Jun 21, 2012)

> This works in such a way that all the scripts are in the "right" spot and all the images are in the "right" spot....



As I see it, the right spot for the scripts is installed in the user's nki which they won't be. For the usual case where the nki is not using the resource thingy, I personally think it's easier to plop down the .nkr somewhere (anywhere will do) and point the instrument to it than it would be to run an installer and possibly have to answer some questions about where something is. But, to each his own. :lol: 

Rejoice,

Bob


----------



## Big Bob (Jun 22, 2012)

Hi Lindon,

I want to warn you about something I just discovered in the process of checking out my posted idea for multiple scripts that use custom graphics. Since you seem to be leaning toward writing an installer, what I just uncovered may impact your thinking.

When an instrument *doesn't* use the Resource thingy, K4 looks for custom graphics in two places, for Windows, one of them is under NI's folder in *Common Files *and the remaining place is in the ...MyDocs/NI/K4/pictures area we have been discussing and you are planning to use.

However, *and here is the Caveat*, when the .nki *does* point to a .nkr (whether the folder structure is present or not), *K4 no longer looks for the graphics in either Common Files or in the 'user' area.* I suspect K5 is the same but I haven't checked it yet.

Therefore, your idea of an installer may not work for the case when the nki already has another script using custom graphics (if that script was distributed or installed in the instrument with a .nkr file). Whereas the method I suggested, does work for this situation as well as the solo script situation.

I don't know if there is any way an installer could detect whether or not an instrument is pointed to a .nkr file. If you can detect this condition some how, then you could have the installer create a Resource folder structure alongside the .nkr (if it doesn't already exist, etc). However, right off hand I can't think of any way to detect this.

Rejoice,

Bob

*BTW Please let me know if and when you read this post. Since you may no longer be watching this thread and I was previously the last poster, this warning may be missed. So, if I don't see a response from you, maybe I'll start a new thread with this little caveat.*


----------



## Lindon (Jun 25, 2012)

Bob,

Hmmm, thanks for this VERY useful info. Now I'm a bit stuck...in that I probably cant use custom graphics in my scripts if I want them to be scripts users can apply to ANY of their instruments....it all seems to be very hard to do....but of the methods available it seems the one you suggest Bob is best. Either the user copies my custom graphics library to the Pictures folder in each instrument, or creates a resource container for each instrument and copies the folder there...

NOT elegant. NOT nice. 

Hang on I guess I could create a "Std resource container" that all instruments WITHOUT their own RC could point to.....so that makes the "non-resource container using instrument" scenario easier to deal with...Oh hang on further, this is EXACTLY what you proposed Bob about 3 posts ago....silly me.


----------



## mk282 (Jun 25, 2012)

Methinks that for all generic scripts, using generic graphics is the best way...


----------



## Big Bob (Jun 25, 2012)

mk282 @ Mon Jun 25 said:


> Methinks that for all generic scripts, using generic graphics is the best way...



I guess it would depend on what you consider a 'generic script' :roll: 

For example, I intend the WIPS scripts to be used with user-designed or user-modified instruments, and, possibly with another 3rd party script say for microtuning or other custom pre-processing. So, in this sense, I guess WIPS will be a 'generic script' suite.

Custom graphics can provide a lot more than cosmetic appearance improvement. To limit the WIPS control panels to only 'generic' graphics would result in a severe limitation of functional usefulness. For example, the WIPS articulation script uses a scrollable list box that displays all instrument groups and is used to make it easy to add groups to a new articulation being built. This listbox is made up of many re-skinned 'generic' components. Without the custom graphics it would be almost useless. This is only one example of how custom graphics adds important functionality.

I really don't see what the BIG problem is with installing 3rd-party scripts that use custom graphics. :? It seems to me that anyone who wants to use a 3rd-party script, needs to be willing to learn a few things about K4/5 such as how to load a .nkp script and how to copy an .nkr file (and point the instrument to it). If the user can't follow a few simple instructions to install such scripts, he probably won't be able to use the scripts properly either. 

In any case, I intend to release WIPS with custom graphics and if this seems to be a major deterent, then I guess those that will benefit from me sharing WIPS with them will be a smaller and more exclusive club. :lol:

Rejoice,

Bob


----------



## Big Bob (Jun 25, 2012)

> Hang on I guess I could create a "Std resource container" that all instruments WITHOUT their own RC could point to.....so that makes the "non-resource container using instrument" scenario easier to deal with...Oh hang on further, this is EXACTLY what you proposed Bob about 3 posts ago....silly me.



*Yes indeed, it's actually very simple when the instrument is currently NOT using the Resource feature. All you need to do is deliver your script with a 'packed' .nkr file. Instruct the user to put the .nkr file anywhere he pleases and then open instrument options and point the instrument to where he put it.*

I mistakenly thought that most users already knew how simple the above situation is to perform so my original post to this thread was to address the *more complex situation *when the instrument already has a script installed that currently uses its own .nkr file. Even that complication is not really all that difficult to deal with. Its really just a matter of providing a clear set of installation instructions and of course the inevitable reluctance of users to read such instructions :lol: .

Rejoice,

Bob


----------

