# KSP load_array function



## kotori (Feb 19, 2011)

Hi everyone,

I thought I'd try to save others the headache of figuring out how to invoke the load_array from the init callback (especially since it's not documented by NI yet). If you want to load an array from an nka file during the initialization phase then the following will _not_ work:

*on init*
``*declare* myarray[10]
``load_array(myarray, 1)
*end on*

In order to make it work use the helper function below:

*function* load_array_in_init_callback(array)
``read_persistent_var( array )
``load_array( array, 1 )
*end function*

*on init*
``*declare* myarray[10]
``load_array_in_init_callback(myarray)
*end on*

The reason is that load_array(array, 1) within the init callback is functionally equivalent to:
load_array(array, 1)
make_persistent(array)
and since the persistent values are by default read at the end of the callback these values will override whatever was read from the .nka file unless one uses read_persistent_var in order to inhibit this behaviour. Don't ask me why it works this way :shock: Boy, was I confused until I found out. 

Cheers,
Nils


----------



## Big Bob (Feb 19, 2011)

Thanks Nils.

I didn't even know there was load_array function or an nka file type. :oops: Boy, have I got the catching up to do :lol: 

BTW since K4 now allows 'callable' user functions, it occurs to me that some of my prior code like SIPS could run into trouble because I defined a KScript function named 'Call'. I then used this function to compile pseudo calls of RCB-dispatched procedures. I haven't haven't had a chance to look into this yet but since your editor makes decisions between KScript functions and KSP functions based on whether or not they are 'called', am I in trouble?

Bob


----------



## kotori (Feb 19, 2011)

Big Bob @ Sat Feb 19 said:


> Thanks Nils.
> 
> I didn't even know there was load_array function or an nka file type. :oops: Boy, have I got the catching up to do :lol:



It's a K4.2 feature. You can find the newest version http://www.native-instruments.com/forum/showthread.php?t=130226 (here). It's a beta, but in my opinion more stable than many of the K2 and K3 release versions.



> BTW since K4 now allows 'callable' user functions, it occurs to me that some of my prior code like SIPS could run into trouble because I defined a KScript function named 'Call'.



If you use a capital C and pass it parameters I don't think the compiler should confuse your function with the keyword, so I think you should be ok.

Cheers,
Nils


----------



## Big Bob (Feb 19, 2011)

> If you use a capital C and pass it parameters I don't think the compiler should confuse your function with the keyword, so I think you should be ok.



Thanks Nils,

Fortunately, I think I did always use a capital C in my usage of the Call function so I'm relieved to hear my old stuff might be OK as is. For new stuff, needless to say, I can easily avoid any conflicts.

Also thanks for the K4.2 beta link, I just downloaded it but haven't installed it yet. Does it include any documentation of its new features or is documentationless :lol: 

You have a great day my friend.

Bob


----------



## kotori (Feb 19, 2011)

Big Bob @ Sat Feb 19 said:


> Also thanks for the K4.2 beta link, I just downloaded it but haven't installed it yet. Does it include any documentation of its new features or is documentationless :lol:


It includes updated documentation. The load_function is documented too. It's just that this very important aspect of it was not documented.


----------



## Big Bob (Feb 19, 2011)

Wow! After installing K4.2 and skimming the new KSP guide, etc, I'm starting to drool at the prospect of using all this spiffy new stuff :mrgreen: 

I really need to thank you again for linking me to K4.2 because I wouldn't want my head to just explode slowly with getting up to speed using only K4.1.3 when I can make it explode quicker trying to absorb all the additional goodies added in K4.2 :lol:

Looks like some really great fun ahead if I can survive the shock :shock: 

Rejoice,

Bob


----------



## EvilDragon (Feb 19, 2011)

Does that mean SIPS 3, Bob? :lol:

IMHO, SIPS and other scripts of yours have a bit too crowded interface, which was limitation of K2. Now you can use much bigger interfaces, using set_ui_height_px(350) in ICB as your maximum UI size. 

BTW, same value applies to multiscripts. Oh, and don't forget that you can use custom graphics too - in K4.2 with Resource Containers it's even better to include them!


----------



## kotori (Feb 20, 2011)

EvilDragon @ Sun Feb 20 said:


> Oh, and don't forget that you can use custom graphics too - in K4.2 with Resource Containers it's even better to include them!


I don't believe using a Resource Container would work for a general purpose script though. But it's of course a good advise for other types of situations.


----------



## EvilDragon (Feb 20, 2011)

It might? Would be worth a shot, dunno...


----------



## Big Bob (Feb 20, 2011)

> Does that mean SIPS 3, Bob?



No Mario, I don't think there will be a SIPS 3 but I do plan to resume my interrupted work on WIPS (Wind Instrument Performance Suite). Virtual wind instruments are my main interest and reason for getting involved in all this stuff in the first place.

However, I am aware of all the new goodies available for constructing user interfaces and fully intend to take advantage of them (that is as soon as I get them all sorted out).

And as far as the new Resource Container, I spent all of 2 minutes reading about it late yesterday so I don't yet have a good feel for its usefulness. Generally it seems like a nice idea to keep things organized better but Nils, why do you say that it might not be too good for a general purpose script?

But, maybe I should study this a bit more before I ask any really stupid questions because I may not even understand the answers I get :lol:


----------



## kotori (Feb 20, 2011)

Big Bob @ Sun Feb 20 said:


> And as far as the new Resource Container, I spent all of 2 minutes reading about it late yesterday so I don't yet have a good feel for its usefulness. Generally it seems like a nice idea to keep things organized better but Nils, why do you say that it might not be too good for a general purpose script?


I just mean, that the user would need to then not only load the scripts but also go into instrument options and point to the right resource container for every new instrument they want to use it on. So it's a bit less user-friendly and when more instruments start to use resource containers there could arise situations where an instrument already has another resource container assigned. But if those things don't pose too big of a hurdle, then resource containers are very nice indeed.



> But, maybe I should study this a bit more before I ask any really stupid questions because I may not even understand the answers I get :lol:


I don't think you should underestimate the usefulness to others of having technical aspects of scripting discussed in open, so don't hesitate to ask if there is anything that could help you come up to speed with the new features. In your case people often benefit doubly since both the discussion itself and the scripts that you produce could be helpful. Just my $0.02.

Cheers,
Nils


----------



## Dynamitec (Feb 20, 2011)

I completely agree with Nils! Open discussions will help everyone and could be interesting for everyone who hasn't used the new stuff in K4.1 or 4.2 yet!

Regarding the resource container and the new graphical possibilites : I think it's not practical and not necessary to have custom graphics in such general purposes scripts.

I should also mention that I'm not a fan of yet another GUI demo either. Don't get me wrong! I think GUI design is definitely important in libraries. But it's way more important what the scripts are adding to the playability of an instrument than having a nice UI. 

What I mean is this: back when Kontakt 2 and this forum here were new, there were a lot of discussions of how to achive different things with Kontakt which haven't been possible with any other sampler. Nowadays, I have the feeling that a lot of focus is on the UI design and not the technical aspects 'under the hood'. 

Frankly, I'm much more impressed by the Math library Bob did back then or for example the engine behind the sampling modelling libraries, than I am with a game engine written in KSP or some GUI tricks. In K2 GUI design was tricky --- I remember how we figured out how to use a special background color behind labels so they were transparent later. The GUI of the Scarbee basses (Nils work) back than was a good example for a GUI using all tricks available in K2 --- and back then every new idea was helpful, but today it's really not too hard anymore.

Ok, I have to say, that I was sharing more of my knowledge back then than I do today, so I understand that not everyone wants to share secrets or completely new approaches to some old problems regarding sampled instruments. 

But still, it would be nice! Anyone wants to implement a neural network in Kontakt? That would be something cool!


----------



## EvilDragon (Feb 20, 2011)

Yes - Math library is surely great, but it can add some CPU overhead depending on in which callback it was used (CCB seems to be the worst). Native math functions (plus floating point processing!) would be a big thing for Kontakt.


Did you guys hear about PLAY Pro? They are using Python for scripting - and not some arbitrary limited version of it. Now that's BIG (my eyes glared when I saw the line #include <math.h> on that screenshot!). Let's just see if EW won't screw up on actual usability, stability and compatibility, as has been the case in the past of PLAY engine.


----------



## Mike Greene (Feb 20, 2011)

kotori @ Sun Feb 20 said:


> I don't think you should underestimate the usefulness to others of having technical aspects of scripting discussed in open, so don't hesitate to ask if there is anything that could help you come up to speed with the new features. In your case people often benefit doubly since both the discussion itself and the scripts


Absolutely! I learn a ton of stuff as I read these discussions and it's very helpful if one of the bigger boys asks questions that I don't understand enough yet to even ask.


----------



## Dynamitec (Feb 20, 2011)

> Did you guys hear about PLAY Pro? They are using Python for scripting - and not some arbitrary limited version of it. Now that's BIG (my eyes glared when I saw the line #include <math.h> on that screenshot!). Let's just see if EW won't screw up on actual usability, stability and compatibility, as has been the case in the past of PLAY engine.



I heared about it. But I still wouldn't bet on PLAY. NI has gained quite a bit of reputation in the last years. Back in K2 and K3 times feature requests and NI support haven't been what users would have wished for. But I think NI has learned quite a bit and their recent focus on Kontakt and Kontakt libraries is helping their sampler, too. And each Kontakt version is getting more stable, while PLAY still seems to struggle especially with new versions.

But: I definitely would like to see is a competition product which puts some pressure on NI to add a real programming language and a better development interface (the group and mapping editor in Kontakt is pretty much unusable for bigger libraries). In my opinion it's ridiculos that we have to deal with rounding errors due to integer math only and that arrays are limited to 32768 elements (which is quite an improvement over the 512 we had in the beginning however). Not to mention that we don't have real functions or ... a text input field ...string functions... any kind of debugger...file access (other than save/load array)...midi file read/playback and write functions...and so on... :|


----------



## Big Bob (Feb 20, 2011)

> What I mean is this: back when Kontakt 2 and this forum here were new, there were a lot of discussions of how to achive different things with Kontakt which haven't been possible with any other sampler.



Ah yes, Benjamin, those were the 'good ol' days weren't they? When we spent most of our time trying to figure out 'how to make a silk purse out of a sow's ear'. :roll: 

Well, I'm sure you are familiar with the old phrases 'necessity is the mother of invention' and 'where there is a will, there is a way'.

Personally, I am very happy that this forum continues to be a place where everyone is willing to share ideas in a way that we all benefit from. I'm sorry that I haven't been able to contribute too much over the last few years but hopefully I can start to make up for it now. It's also wonderful to see so many new, brilliant contributors on the scene. Welcome aboard o=< 

My philosophy is rather simple, 'No one knows everything about everything but, collectively, we can come a lot closer'. So, let's continue to share our knowledge and who knows, maybe we can make a few more 'silk purses'. After all, with K4.2, the sow's ear is getting closer than ever to being a silk purse all by itself. :lol:

Rejoice,

Bob


----------



## polypx (Feb 20, 2011)

I'm very happy to have Bob back in the fold here too. A big welcome back from me, a grateful student.

But it's sobering, in a way, to think that a lot of the "progress" that's been made in KSP in the last year or so since Bob went (on sabbatical) has been focused primarily on GUI functionality, obviously for the KPlayer market, rather than tapping further into the Kontakt engine.

(and most of you know, there are a lot of missing taps)

The cynic in me says this is where NI are making their money. But if you look around at some of the new libraries, the amazing thing IS now the interfaces... there's a wide variety of very clever and unique interfaces. 

But when this all started a few years ago, it was more about getting to the mechanics of the sampler. That's the really interesting stuff. 

I hope Bob and SIPS and so on will redirect some of this forum back towards the guts of the issue, rather than the front panel.

cheers,
Dan


----------



## Big Bob (Feb 21, 2011)

> I thought I'd try to save others the headache of figuring out how to invoke the load_array from the init callback (especially since it's not documented by NI yet). If you want to load an array from an nka file during the initialization phase then the following will not work:



Hi Nils,

Now that I have briefly scanned all the newer stuff in K4.2, I thought I would re-read your post about load_array to see if I could now understand what you were saying so I might benefit from your discovery about the read_persistent thingy. But, unfortunately, I have run into lots of road blocks so here comes some of those dumb questions I promised :oops: 

I figured before I could use load_array, I would first have to figure out how to use save_array so I thought I'd just try saving a simple array filled with constants from 0..5. The documentation doesn't say anything about an .nka file so I guess I still don't know what it is or how to make one. But, the docs indicate a /Data folder will be created alongside my Resource container, which (in the light of what you said in response to my query about that) I was hoping not to have to get involved with, at least not yet :roll: 

So, I thought I would just try to make a simple .nki with a script containing a save_array attempt and then see if it would create the /Data folder next to the .nki (in the absence of a Resource container). But, when I tried to execute a save_arrray in the ICB, K4 says this function can only be used in a ui or pgs callback (even though the docs say it can be used in the ICB provided we use the ,1 format). Your posted example seemed to indicate not that the invokation couldn't be made from the ICB but rather that it might return the wrong values, so I'm a little puzzled by K4's compiler message.

However, to plod ahead, I moved the save_array call to a ui callback and tried again. This at least compiles without error but when I hit my ui button to execute the save_array, I get a status message that the Resource container can't be found.

So, I guess I can only use save_array if I first create the Resource container? 

Needless to say, I can't try your read_array thing until I create an array file somehow and as you can tell from the foregoing, I haven't been very successful with that so far.

Could you (or anyone that wants to jump in here) please elaborate a bit on how one uses save_array and load_array and what exactly is an .nka file and how does it come about? Is that what will be created in the Data folder 'alongside' the Resource thingy. Do, I have to use the Resource thingy in order to use load/save array, etc etc :? 

Bob


----------



## Big Bob (Feb 21, 2011)

> I thought I'd try to save others the headache of figuring out how to invoke the load_array from the init callback (especially since it's not documented by NI yet). If you want to load an array from an nka file during the initialization phase then the following will not work:



Hi Nils,

Now that I have briefly scanned all the newer stuff in K4.2, I thought I would re-read your post about load_array to see if I could now understand what you were saying so I might benefit from your discovery about the read_persistent thingy. But, unfortunately, I have run into lots of road blocks so here comes some of those dumb questions I promised :oops: 

I figured before I could use load_array, I would first have to figure out how to use save_array so I thought I'd just try saving a simple array filled with constants from 0..5. The documentation doesn't say anything about an .nka file so I guess I still don't know what it is or how to make one. But, the docs indicate a /Data folder will be created alongside my Resource container, which (in the light of what you said in response to my query about that) I was hoping not to have to get involved with, at least not yet :roll: 

So, I thought I would just try to make a simple .nki with a script containing a save_array attempt and then see if it would create the /Data folder next to the .nki (in the absence of a Resource container). But, when I tried to execute a save_arrray in the ICB, K4 says this function can only be used in a ui or pgs callback (even though the docs say it can be used in the ICB provided we use the ,1 format). Your posted example seemed to indicate not that the invokation couldn't be made from the ICB but rather that it might return the wrong values, so I'm a little puzzled by K4's compiler message.

However, to plod ahead, I moved the save_array call to a ui callback and tried again. This at least compiles without error but when I hit my ui button to execute the save_array, I get a status message that the Resource container can't be found.

So, I guess I can only use save_array if I first create the Resource container? 

Needless to say, I can't try your read_array thing until I create an array file somehow and as you can tell from the foregoing, I haven't been very successful with that so far.

Could you (or anyone that wants to jump in here) please elaborate a bit on how one uses save_array and load_array and what exactly is an .nka file and how does it come about? Is that what will be created in the Data folder 'alongside' the Resource thingy. Do, I have to use the Resource thingy in order to use load/save array, etc etc :? 

Bob


----------



## Big Bob (Feb 21, 2011)

> I thought I'd try to save others the headache of figuring out how to invoke the load_array from the init callback (especially since it's not documented by NI yet). If you want to load an array from an nka file during the initialization phase then the following will not work:



Hi Nils,

Now that I have briefly scanned all the newer stuff in K4.2, I thought I would re-read your post about load_array to see if I could now understand what you were saying so I might benefit from your discovery about the read_persistent thingy. But, unfortunately, I have run into lots of road blocks so here comes some of those dumb questions I promised :oops: 

I figured before I could use load_array, I would first have to figure out how to use save_array so I thought I'd just try saving a simple array filled with constants from 0..5. The documentation doesn't say anything about an .nka file so I guess I still don't know what it is or how to make one. But, the docs indicate a /Data folder will be created alongside my Resource container, which (in the light of what you said in response to my query about that) I was hoping not to have to get involved with, at least not yet :roll: 

So, I thought I would just try to make a simple .nki with a script containing a save_array attempt and then see if it would create the /Data folder next to the .nki (in the absence of a Resource container). But, when I tried to execute a save_arrray in the ICB, K4 says this function can only be used in a ui or pgs callback (even though the docs say it can be used in the ICB provided we use the ,1 format). Your posted example seemed to indicate not that the invokation couldn't be made from the ICB but rather that it might return the wrong values, so I'm a little puzzled by K4's compiler message.

However, to plod ahead, I moved the save_array call to a ui callback and tried again. This at least compiles without error but when I hit my ui button to execute the save_array, I get a status message that the Resource container can't be found.

So, I guess I can only use save_array if I first create the Resource container? 

Needless to say, I can't try your read_array thing until I create an array file somehow and as you can tell from the foregoing, I haven't been very successful with that so far.

Could you (or anyone that wants to jump in here) please elaborate a bit on how one uses save_array and load_array and what exactly is an .nka file and how does it come about? Is that what will be created in the Data folder 'alongside' the Resource thingy. Do, I have to use the Resource thingy in order to use load/save array, etc etc :? 

Bob


----------



## Big Bob (Feb 21, 2011)

Hi Nils,

Now that I have briefly scanned all the newer stuff in K4.2, I thought I would re-read your post about load_array to see if I could now understand what you were saying so I might benefit from your discovery about the read_persistent thingy. But, unfortunately, I have run into lots of road blocks so here comes some of those dumb questions I promised :oops: 

I figured before I could use load_array, I would first have to figure out how to use save_array so I thought I'd just try saving a simple array filled with constants from 0..5. The documentation doesn't say anything about an .nka file so I guess I still don't know what it is or how to make one. But, the docs indicate a /Data folder will be created alongside my Resource container, which (in the light of what you said in response to my query about that) I was hoping not to have to get involved with, at least not yet :roll: 

So, I thought I would just try to make a simple .nki with a script containing a save_array attempt and then see if it would create the /Data folder next to the .nki (in the absence of a Resource container). But, when I tried to execute a save_arrray in the ICB, K4 says this function can only be used in a ui or pgs callback (even though the docs say it can be used in the ICB provided we use the ,1 format). Your posted example seemed to indicate not that the invokation couldn't be made from the ICB but rather that it might return the wrong values, so I'm a little puzzled by K4's compiler message.

However, to plod ahead, I moved the save_array call to a ui callback and tried again. This at least compiles without error but when I hit my ui button to execute the save_array, I get a status message that the Resource container can't be found.

So, I guess I can only use save_array if I first create the Resource container? 

Needless to say, I can't try your read_array thing until I create an array file somehow and as you can tell from the foregoing, I haven't been very successful with that so far.

Could you (or anyone that wants to jump in here) please elaborate a bit on how one uses save_array and load_array and what exactly is an .nka file and how does it come about? Is that what will be created in the Data folder 'alongside' the Resource thingy. Do, I have to use the Resource thingy in order to use load/save array, etc etc :? 

Bob


----------



## Big Bob (Feb 21, 2011)

> I thought I'd try to save others the headache of figuring out how to invoke the load_array from the init callback (especially since it's not documented by NI yet). If you want to load an array from an nka file during the initialization phase then the following will not work:



Hi Nils,

Now that I have briefly scanned all the newer stuff in K4.2, I thought I would re-read your post about load_array to see if I could now understand what you were saying so I might benefit from your discovery about the read_persistent thingy. But, unfortunately, I have run into lots of road blocks so here comes some of those dumb questions I promised :oops: 

I figured before I could use load_array, I would first have to figure out how to use save_array so I thought I'd just try saving a simple array filled with constants from 0..5. The documentation doesn't say anything about an .nka file so I guess I still don't know what it is or how to make one. But, the docs indicate a /Data folder will be created alongside my Resource container, which (in the light of what you said in response to my query about that) I was hoping not to have to get involved with, at least not yet :roll: 

So, I thought I would just try to make a simple .nki with a script containing a save_array attempt and then see if it would create the /Data folder next to the .nki (in the absence of a Resource container). But, when I tried to execute a save_arrray in the ICB, K4 says this function can only be used in a ui or pgs callback (even though the docs say it can be used in the ICB provided we use the ,1 format). Your posted example seemed to indicate not that the invokation couldn't be made from the ICB but rather that it might return the wrong values, so I'm a little puzzled by K4's compiler message.

However, to plod ahead, I moved the save_array call to a ui callback and tried again. This at least compiles without error but when I hit my ui button to execute the save_array, I get a status message that the Resource container can't be found.

So, I guess I can only use save_array if I first create the Resource container? 

Needless to say, I can't try your read_array thing until I create an array file somehow and as you can tell from the foregoing, I haven't been very successful with that so far.

Could you (or anyone that wants to jump in here) please elaborate a bit on how one uses save_array and load_array and what exactly is an .nka file and how does it come about? Is that what will be created in the Data folder 'alongside' the Resource thingy. Do, I have to use the Resource thingy in order to use load/save array, etc etc :? 

Bob


----------



## Big Bob (Feb 21, 2011)

Aha, I guess I should have tried saving the array with the ,0 format. Now it lets me create an .nka file at least. But, does this mean that I can't read the array without also using the ,0 format? Hmmm!


----------



## Frederick Russ (Feb 21, 2011)

Big Bob @ Mon Feb 21 said:


> Is there a problem with the forum??? Everytime I try to post something, I get a bunch of weird Debug messages and it just hangs there. However, when I relog in, the post usually is accomplished???
> 
> Maybe I should have stayed in bed a little later this morning :lol:



Hi Bob,

Our server crashed earlier today and with it some elements of the database. This should be repaired now.


----------



## polypx (Feb 21, 2011)

> Could you (or anyone that wants to jump in here) please elaborate a bit on how one uses save_array and load_array and what exactly is an .nka file and how does it come about? Is that what will be created in the Data folder 'alongside' the Resource thingy. Do, I have to use the Resource thingy in order to use load/save array, etc etc



Hi Bob,

The 'nka' is the array file extension when it's on disk. You can save or load these.

The Resource thingy is not necessary to load or save an array in mode 0, since in that mode you have a dialogue window that allows the user to decide WHERE to save or load an array.

In mode 1, save and load array skip the dialogue box, EXPECT the Data folder to exist, and automatically save or load the array from there, with the name of the array being the same as the file name (which means you can only have ONE version on disk, since it's name is fixed).

The Resource thingy is also useful for another reason. Since K4 came out, we've been able to have graphics on UI elements, and other resources such as IR convolution wavs, scripts as text files, etc. But managing this if you weren't developing a KPlayer library was a bit complicated, because the location of the various files was a bit of a mess . Now in 4.2, EVERYTHING goes into the Resource, so you can share that Resource with your friends, customers, etc. and your Instruments will always find their graphics, IRs, scripts, and so on.

cheers
Dan


----------



## kotori (Feb 21, 2011)

Dan already added lots of useful info but one thing that has perhaps not been pointed out clearly enough in this thread is the fact that if the Data and Resources folders are present (and a resource container file set in Instrument Options) then Kontakt will load files from these folders. If Kontakt does not find these folders it will try to load the files from the resource container file (which is essentially these folders compressed into a single file). So the resource container file is a fallback one could say.

Btw. Bob, this is unrelated to this discussion, but before you make too grand plans based on NI's new native support for functions using the "call" keyword it's good to be aware of two things:
Kontakt does not keep track of from which callbacks a function is directly or indirectly invoked using the "call" keyword (it would be very nice if it did). This normally means that built-in functions that are disallowed in some other callback than the init callback cannot be used inside a called function. Perhaps most notably you cannot use allow_group/disallow_group within a function invoked using "call".
If the exit function is invoked within a "call"ed function it does not abort the whole callback - just the function called. I believe this is undocumented.
Cheers,
Nils


----------



## Big Bob (Feb 22, 2011)

Oh Nils,

I just noticed that you said the save_array command *cannot* be used in the ICB. Apparently the KSP manual is incorrect then because it says it *can be used *in the ICB (in the ,1 format)?

Bob


----------



## kotori (Feb 22, 2011)

Big Bob @ Tue Feb 22 said:


> I just noticed that you said the save_array command *cannot* be used in the ICB. Apparently the KSP manual is incorrect then because it says it *can be used *in the ICB (in the ,1 format)?


Yes, then the documentation is wrong. Probably a copy and paste error. On the other hand I cannot see why one would want to use save_array in the init callback anyway.

Nils


----------



## Big Bob (Feb 22, 2011)

> On the other hand I cannot see why one would want to use save_array in the init callback anyway.



No, neither can I (now that I understand it a bit better, but when I was first trying to grapple with the load_array problem you described, I just tried the same ,1 format in the ICB simply to try to create a .nka).

However, now that I'm finally in a better position to understand your original post about the persistence problem connected with load_array, I guess I still don't quite have this under my belt yet :lol: 

I created an array named MyArray[5] (populated with the values 0, 1, 2, 3, 4) and saved it in the data folder. Then I used the following little test script to examine your reported problem.

*on init*
``*declare* ui_button Show
``*declare* ui_label Array(1,1)
``*declare* MyArray[5] := (5,4,3,2,1)
_{ load_array(MyArray,1) }_
*end on*

*on ui_control*(Show)
``set_text(Array,MyArray[0] & ', ' & MyArray[1] & ', ' ...
````````````& MyArray[2] & ', ' & MyArray[3]& ', ' & MyArray[4])
*end on*

Now, if I run this script with the load_array commented out, when I hit the Show button, I see the expected 5, 4, 3, 2, 1 displayed.

Then, I recompile the script with the load_array in the ICB and when I hit the Show button, I see the stored values 0, 1, 2, 3, 4. Then, if I load the 'empty' script to clear the persistence buffer and then recompile the script without the load_array, when I hit Show I again see the 5, 4, 3, 2, 1.

If I don't load the 'empty' script to clear the persistence buffer, I have to of course compile the script without the load_array twice to get back to the 5, 4, 3, 2, 1, and therefore your conclusion that using load_array is probably equivalent to adding a make_persistent command seems to be quite true.

However, I guess I don't fully understand under what conditions you need to force a read of the buffer before the end of the ICB with the read_persisent_var command. It seems to me that using the load_array without the read_persistent_var also does just what I would have expected it to do. So, I must be missing something here that perhaps you could clarify? :? 

Bob


----------



## Big Bob (Feb 22, 2011)

Hey Dan or Nils,

I have one last question about the Resource thingy. The .nkr file is apparently the compressed resource monolith but there also seems to be a .nkc file generated. Do either of you know what this is and what we need to do with it (if anything)?

Thanks,

Bob


----------



## EvilDragon (Feb 22, 2011)

I presume it's exactly the same as the .nkc file that goes along .nkx monoliths - it contains references to the data in the monolith (like, at which location in the monolith the file starts and ends, because in a monolith, all files are stringed into one giant file). So yeah, it's needed. If it's deleted, I presume it's recreated again when anything from RC is pulled.


----------



## Big Bob (Feb 22, 2011)

Hi Mario,

Do you think it's needed when sharing work? According to the manual, after you re-create the .nkr, you can then give the .nkis and the .nkr to other team members. It doesn't mention that you need to give them the .nkc file also. That's the reason I was asking.

Rejoice,

Bob


----------



## EvilDragon (Feb 22, 2011)

Yep, because it'll save time that's needed to recreate .nkc when you load the NKI for the first time. Well depends on the number of files that are monolithed. I'd definitely send both, still.


----------



## Big Bob (Feb 22, 2011)

> Btw. Bob, this is unrelated to this discussion, but before you make too grand plans based on NI's new native support for functions using the "call" keyword it's good to be aware of two things:
> Kontakt does not keep track of from which callbacks a function is directly or indirectly invoked using the "call" keyword (it would be very nice if it did). This normally means that built-in functions that are disallowed in some other callback than the init callback cannot be used inside a called function. Perhaps most notably you cannot use allow_group/disallow_group within a function invoked using "call".



Thanks for this info Nils. It's too bad NI rejects possibly illegal stuff like allow_group at compile time instead of at runtime. Otherwise we might be able to do something like this:

*function* select_group
``*if* (NI_CALLBACK_TYPE = NI_CB_TYPE_NOTE) *or* (NI_CALLBACK_TYPE = NI_CB_TYPE_RELEASE)
````disallow_group(ALL_GROUPS)
````*if* NI_CALLBACK_TYPE = NI_CB_TYPE_RELEASE
``````allow_group(PlayGroup + RELEASE_OFFSET)
````*else*
``````allow_group(PlayGroup)
````*end if*
``*else*
````message('Cannot Select a group from this callback type')
``*end if*
*end function*

That is assuming that these callback type thingies actually work as advertised :lol: 

You have a great day my friend.

Bob

And thanks Mario for your response that slipped in while I was posting this.


----------



## kotori (Feb 22, 2011)

Big Bob @ Wed Feb 23 said:


> Thanks for this info Nils. It's too bad NI rejects possibly illegal stuff like allow_group at compile time instead of at runtime. Otherwise we might be able to do something like this: (...)


I agree. But personally I think what would make sense would be for NI to do an analysis of the call graph during the static phase. It's very easy - one just uses a bitmask indicating which set of callbacks that directly/indirectly invoke each function.

Cheers,
Nils


----------



## Big Bob (Feb 24, 2011)

Just want to mention that if you have been following this thread, I've started a new thread to continue with my noobie questions and re-discoveries. :roll: 

Check it out, who knows what might get posted there. 

http://www.vi-control.net/forum/viewtop ... 0083ba7c62

Rejoice,

Bob


----------



## Big Bob (Apr 20, 2011)

I thought I finally understood all this but, now I wonder.

Lets say that one creates a Resources and Data folder set for a given instrument and then points the Instrument to the Resources Folder. Now let's say that we use save_array to store one or more arrays in the Data folder.

Now, in instrument options I ask to create the resource again so K4 now updates the .nkr file with all the current contents of the resources folder. Now I thought that if I sent the .nki and the .nkr to someone, when they loaded the .nki, the .nkr file would be read and it would not only provide the pictures, etc but that it would also provide the .nka files from the Data folder. So, if the .nki has a script that uses load_array(x,1) in the ICB, shouldn't it be able to load the array from the .nkr?

Apparently that's not the case. It seems as though one also needs to send the Data folder and the .nka files it contains. The .nkr is also needed but apparently only to point the .nki to the Data folder. If the Data folder is missing the .nka files cannot be read from the .nkr alone? If this is true, then we also have to send a team member the Data folder?

Is this correct or am I still not understanding this???? :? 

Confused as ever,

Bob


----------



## polypx (Apr 20, 2011)

As far as I understand the Data folder is outside the .nkr or the Resources completely. So if you're using any .nka's in the Data folder you need to send that too.

I could be wrong, but that's how I understand it. The resource includes pictures, scripts, irs, that's all.

cheers
Dan


----------



## EvilDragon (Apr 21, 2011)

Yes, Data folder is outside of Resources folder. But they both get packed to .NKR.


----------



## Big Bob (Apr 21, 2011)

Hi Dan,

Yes that indeed does seem to be the way it works but I know that others have indicated that the .nka files from the Data folder are encoded into the .nkr.



> Yes, Data folder is outside of Resources folder. But they both get packed to .NKR.



Hi Mario,

That's what I thought would happen but, I can't seem to make it happen. For my tests I'm just using the default instrument with no samples, pixes, or IRs. the .nki therefore is about as simple as it gets with just a very simple script using load_array(X,1) [after a read_persistent_var] in the ICB. The Data folder simply contains one .nka file named X.

First, in instrument options, I point the instrument to the Resources folder (which of course just contains 3 empty sub folders). Then I re-create the resource container to 'update' the .nkr file. Now, if I delete (or rename) the Resources folder, when I load the .nki, I can clear the persistence buffer (by loading the empty script) and then recompile the script, it still loads the .nka file from the Data folder. ie the resource path in the instrument options is now pointing to the .nkr (since the Resources folder is missing). 

However, if I now delete the Data folder, and repeat the above, the script with load_array no longer loads the X array. This would surely seem to indicate that the .nka info *is not *encoded in the .nkr file, no? So, if what you are saying is correct, then, what am I doing wrong?

All my testing so far indicates that the .nka files must be in a Data folder in the same place it was when the .nkr was recreated (supposedly with the .nka info encoded into it). However, I should point out that if the Resources folder is missing, the .nkr must be present in addition to the Data folder. But, apparently, the .nkr file merely acts as a path pointer for the instrument to find the Data folder?

I would sure like to get this situation resolved so any further words of wisdom would be much appreciated.

Thanks,

Bob


----------



## Big Bob (Apr 21, 2011)

Just in case my problem stems from having all the sub-folders empty, I put the load_array script in the scripts folder under the Resources folder. Then, I re-created (updated) the .nkr. Now, when I rename the Resources folder and reload the .nki, when I try to load the script from the .nkr that doesn't seem to work either :? . 

As long as the Resources folder is named Resources, the script can be accessed via the Apply from menu by choosing from Resources folder. Once I rename Resources to MyResources, the apply from menu no longer includes any resources folder choice so apparently the updated .nkr doesn't contain the script either. :shock: 

Is there some step I'm missing here?

I'm attaching the test folder containing my .nki, .nkr, etc in the hopes that one of you can try this to see if you can unravel this mystery.

1. Unzip the .rar and put the TrigTest folder (and its contents) some convenient place

2. Load the TrigTest.nki into K4.

3. Apply the LoadTrig script from the Resources folder.

4. Run the test program by changing the angle edit box and note displayed sine and cosine.

5. In instrument options, re-create or update the .nkr to supposedly include the LoadTrig script and possibly the Sin.nka file from the Data folder.

6. Close the instrument.

7. Rename the Resources folder MyResources.

8. Load the TrigTest.nki again and try to find the script via the Apply button. I can't find it.

9. However, if you load the script into the clipboard and then Apply it in the script editor, you can still successfully run the test program. But, if you now rename the Data folder to MyData, and then reload the instrument and the script, the program will only show sin=0, cos=0 for any angle setting, meaning that the Sin array did not get loaded.

Can anyone explain what I'm doing wrong here???

Thanks,

Bob


----------



## Big Bob (Apr 21, 2011)

More confusion. I tried adding a picture to the Resources sub-folder for pictures. Then I re-created the .nkr to include the picture (along with the script and the .nka supposedly). In this case, if I rename the Resources folder to MyResources, the script can still access the picture (apparently from the .nkr), so this at least appears to work OK. However, the .nka still cannot be read from the .nkr (if I rename the Data folder).

So, either the .nka file does not get packed into the .nkr, or the load_array function doesn't know how to retrieve it, or, I simply don't understand this at all :roll: 

Also, since one cannot Apply scripts from the .nkr (at least one cannot choose the 'from resource' option in the menu), how can a team member access these scripts if you only send him the .nkr??? :? :? 

BTW I notice that no one even downloaded the attachment from my last post so maybe no one that knows anything about the Resource thingy is reading this thread??

HELP!!

I sure hope someone can restore my santity soon. :lol: 

Bob


----------



## EvilDragon (Apr 21, 2011)

You CAN apply scripts from .nkr, but you need to have a folder called "scripts" inside Resources folder before you pack it as an .NKR. I've tried it and it works.


Oh, and Data folder doesn't get saved into .NKR monolith, I believe. This is to make reading and writing .NKA files easier instead of constantly rewriting the monolith when array(s) is/are resaved, I presume.


----------



## Big Bob (Apr 21, 2011)

Hi Mario,



> Oh, and Data folder doesn't get saved into .NKR monolith, I believe. This is to make reading and writing .NKA files easier instead of constantly rewriting the monolith when array(s) is/are resaved, I presume.



Hallelujah! Thank you for restoring my sanity. So then you agree that if I want to give my .nka files to a team member, I do need to give him the .nka files apart from the .nkr (and he needs to put it in a Data folder alongside where the .nkr is saved)?

That's the only way I was able to get the thing to work. Without the Data folder, she no fly >8o Yet you, and others were saying that the .nka files were packed into the .nkr, and that's what threw me :roll: 



> You CAN apply scripts from .nkr, but you need to have a folder called "scripts" inside Resources folder before you pack it as an .NKR. I've tried it and it works.



Well, I did have the script in the Resources sub-folder named scripts. However, I think the problem here is my expectation was different. When the Resources folder is still present, one can load any script from the scripts sub-folder and compile it. So I was hoping that I could provide a team member with several alternate scripts that they could load and compile at different points in time, like they could if I sent them the whole Resources folder. Now my mistake was thinking that after updating the .nkr, all the team member would need is the .nkr and they could still load any of the scripts at any point in time (from the .nkr).

Instead, apparently the way it works is that:

1. While the Resources folder is *still present*, you have to select the script you want using the Apply from resource menu option and then ..

2. Resave the .nki *This step I was not doing*

3. Then if one renames or removes the Resources folder, when one reloads the .nki, it *will* load the script from the .nkr.

But now, you can no longer choose an alternate script from the .nkr as you could have when the Resources folder was present.

Therefore, I guess the only real advantage to packing scripts into the .nkr is if one has multiple .nki files that all are pointed to the same .nkr. Then, if one goes through the process of updating first the script and then the .nkr, all the .nki files that are pointed to the .nkr will now get the new updated script when they are reloaded. Is that basically the big feature?

If so, I guess it might be nice when you have a lot of instruments using the same script, but, it's certainly not useful for script interchanging with a single instrument as I was trying to use it :( 

Thanks again for your prompt response

Rejoice,

Bob


----------



## EvilDragon (Apr 21, 2011)

Big Bob @ 22.4.2011 said:


> Therefore, I guess the only real advantage to packing scripts into the .nkr is if one has multiple .nki files that all are pointed to the same .nkr. Then, if one goes through the process of updating first the script and then the .nkr, all the .nki files that are pointed to the .nkr will now get the new updated script when they are reloaded. Is that basically the big feature?



Yes, this seems to be the case from my perspective as well.


----------



## polypx (Apr 21, 2011)

... and revised pictures or impulse responses.

It's kind of a convenient single-file way to update all that "extra" stuff, aside from the samples themselves.


----------

