What's new

KSP: any insight into this mysterious bug?

@EvilDragon: The generated ICB is 2256 lines long. However, it doesn't get longer when I increase array sizes past the buggy limit.

@d.healey: Yes I allowed for bigger arrays than I actually need in order to make this engine re-usable. I could of course bring the specs down without much loss. However, not knowing the cause of this bug worries me, because I'm afraid it comes back later, at a point where I can't just discard a feature and keep moving on.

I also feel like the code is overcomplicated. However every time I complicate things, before doing so, I think "like really hard" to make sure there's no simpler way. I don't know, maybe I still overlooked possibilities.

@Lindon: if 1=1: Could you please elaborate? I used to know but I forgot what it is. I often comment out parts of the code to see how it goes, and I suppose if 1=1 is a similar technique?
 
Last edited:
With 2250 lines in ICB there's no need for 1=1 workaround. It must be something else triggering parser stack overflow then.
 
Yes, i don't know the limit (and i've never seen the stack overflow error, because i'm good at predicting errors... :D), but i got something with almost 3000 ICB lines right now on a project. No issues here.

@Fredeke
Consider loading external arrays in the ICB, if possible for your project. (i'm not sure it will help with parser stack errors, but it simplifies the code a lot anyway).

If you jump over to 6.2, take a look at the ui_panel control and load_performance_view() command. I still haven't had a chance to try those myself, but judging by their description alone, they should make the UI building process a lot easier.
 
I don't see it.
Yeah, sorry. I should have deleted that line. In fact the code was too long for a VI post. It got refused even after I tried some trimming.
@Fredeke
Consider loading external arrays in the ICB, if possible for your project. (i'm not sure it will help with parser stack errors, but it simplifies the code a lot anyway).
Are you suggesting load_array() ? So I would need a temp. script to save the array first as well?
Yes, I suppose I can do that.
If you jump over to 6.2, take a look at the ui_panel control and load_performance_view() command. I still haven't had a chance to try those myself, but judging by their description alone, they should make the UI building process a lot easier.
God, you're so right. Every day I resist the temptation to do that, because I want the instrument as retro compatible as possible, but it's a real pain and the code needs to be sooooooo long just to achieve so little!

If you guys can convince me that I'm wrong, I won't need much push before I finally decide to upgrade ;)
 
Last edited:
Are you suggesting load_array() ? So I would need a temp. script to save the array first as well?
Yes, I suppose I can do that.

Yeah, i mean, if you got a lot of static data, specially string arrays which don't support initializers... :(
You just keep that data inside the resource container and it's less stuff cluttering the script.

But this is on a case-by-case basis. Of course, it depends on your application.

You can create the scripts externally, no need to use a secondary script to generate them, although it's easier sometimes... again, it depends.
 
Yeah, i mean, if you got a lot of static data, specially string arrays which don't support initializers... :(
You just keep that data inside the resource container and it's less stuff cluttering the script.
It sounds like a very good idea. Of course when I want to change the config, I'd need to re-generate them, but that's a minor hassle.
specially string arrays which don't support initializers... :(
Would you educate me as to what initializers are ?

Btw, I don't suppose real arrays are saveable yet ? I guess I could do without them, it would just be more rewrite :-/
(Or just offload integers and strings, and keep reals in-script... But that would be awkward)

You can create the scripts externally, no need to use a secondary script to generate them
Once again, I'm not sure what you mean.
 
Would you educate me as to what initializers are ?

Constants, variables and arrays can be initialized, aka declared and assigned a value in one line.

declare $x := 1

Strings (both variables and arrays) do not support this.
You need to declare and assign on separate lines.

declare @1
@1 := "string".

Maybe sKSP allows for string initialization (i'd need to check), but after compiling, the generated code will still create all those extra lines.
If you have, let's say... 200 controls (each with control help and automation names), that's 800 lines of code just in string declaration and assignment.

This the the worst case scenario (well, also consider preset names, or sounds, or anything else in a large scale where you'd need a lot of string data).


Btw, I don't suppose real arrays are saveable yet ? I guess I could do without them, it would just be more rewrite :-/
(Or just offload integers and strings, and keep reals in-script... But that would be awkward)

Good question. I'm not sure if real arrays can be saved. It's not that awkward saving integers and then re-converting them in the script. I actually did that not long ago (because i wanted to keep integer and float data in the same array).


Once again, I'm not sure what you mean.

If you want to create and array, you can use a simple text editor like notepad++.
There are some rules for making the nka compatible with Kontakt, though.

For example, the first line must include the array name, and the last line must be left empty.
Some attention must be taken in order to keep the line breaks compatible too, i think.

Honestly, i don't remember all the rules... i just write them down and they normally work.
Maybe tweak the EOL conversion if it doesn't seem to be working correctly. (if it's set to LF (Unix), try CR LF (Windows)).
Normally one of those works.
 
Constants, variables and arrays can be initialized, aka declared and assigned a value in one line.
I get it. It's less of an issue in the case of a large string array (like I use here), because I couldn't condense all content in one line anyway. (And yes, hundreds of lines of declaration - you're just twisting the knife in my wound ;))

Good question. I'm not sure if real arrays can be saved. It's not that awkward saving integers and then re-converting them in the script. I actually did that not long ago (because i wanted to keep integer and float data in the same array).
Sure, there are several ways around that. In this case, since all the reals I use span from -24.00 to +24.00 (yes, it's just semitones.cents), I could just multiply everything by 100 and use integers. Reals seemed a simpler choice at some point, but if they become a complication, I could dispense with them easily.

If you want to create and array, you can use a simple text editor like notepad++.
Ah, yes. You're talking about manually writing an nka in a text editor. I never opened one as text to see what it was made of (I did that with the PHP equivalent, and it was so compacted, I wouldn't dare to edit it by hand). But if it is Human friendly enough, then yes that would be an excellent solution. Probably more convenient than a KSP script actually !

I had another idea, but probably won't implement it because your suggestion seems better: since I never need the whole content of the arrays at once, but only load one preset at a time, I could PGS its declaration to another script, and then just pass the values I need, when I need them. The master script would ask for an index through PGS, and the config script would return a value the same way.

But if your solution solves the stack overflow issue, then it's just better.

Ok, I've got some work to do...
 
Last edited:
Ah, yes. You're talking about manually writing an nka in a text editor. I never opened one as text to see what it was made of (I did that with the PHP equivalent, and it was so compacted, I wouldn't dare to edit it by hand). But if it is Human friendly enough, then yes that would be an excellent solution. Probably more convenient than a KSP script actually !

You could try this example. Quick and dirty (don't mind the all caps names).

Code:
on init
    make_perfview
    
    declare $counter
    declare $async_id := -1
    
    declare ui_button $NEXT_LINE
    declare ui_button $LOAD
    
    declare ui_label $TEXT (4, 1)
    
    declare const $BUFFER_SIZE := 4
    declare !buffer[$BUFFER_SIZE]
end on

function displayText
    set_text($TEXT, !buffer[$counter])
end function

on ui_control($LOAD)
    $counter := 0
    $async_id := load_array(!buffer, 0)
end on

on ui_control($NEXT_LINE)
    inc($counter)
    
    if($counter >= $BUFFER_SIZE)
        $counter := 0
    end if
    
    call displayText
end on

on async_complete
    if($async_id= $NI_ASYNC_ID)
        $async_id := -1
        
        call displayText
        $LOAD := 0
    end if
end on

And use the attached nka to test it. It was created manually.
When in doubt, use Notepad ++, check the lines, the EOL and it should work without too many issues.

I had another idea, but probably won't implement it because your suggestion seems better: since I never need the whole content of the arrays at once, but only load one preset at a time, I could PGS its declaration to another script, and then just pass the values I need, when I need them. The master script would ask for an index through PGS, and the config script would return a value.

Yes, you can pass string data with PGS too, i think i posted that as an example somewhere on this forum.
But... yeah, it's overcomplicating a bit, i think.
 

Attachments

  • test.rar
    142 bytes · Views: 6
And use the attached nka to test it. It was created manually.
When in doubt, use Notepad ++, check the lines, the EOL and it should work without too many issues.
I get it. It's super simple!

Now, all I need to be careful about is to keep all NKAs line-synced. Because element X of one array needs to correspond to element X of other arrays. Since professional text editors show line numbers, that shouldn't be too difficult.
Would you happen to know of a text editor that can show different files in different columns, and scroll them all in sync, per chance? I guess I could code that myself, but that would become a rather long detour... Oh wait, maybe I should investigate using a spreadsheet editor and then renaming .csv files into .nka ;)
 
Last edited:
Would you happen to know of a text editor that can show different files in different columns, and scroll them all in sync, per chance?

No, but if your script allows for the creation of arrays that follow a logical element sequence, than you don't need to worry too much about it, i think...

I guess I could code that myself, but that would become a rather long detour... Oh wait, maybe I should investigate using a spreadsheet editor and then renaming .csv files into .nka

I wonder what you're doing over there. :)
 
I wonder what you're doing over there. :)
I store presets in arrays. Since presets have more than one parameter, there's one array per parameter. First I tried defining a preset's content as a struct, and then declaring an array of structs, but it caused endless problems so now it's just a bunch of loose arrays.

Anyway, I think I'll just convert my presets script (which is already an import) into an nka-generating script. In this case, it's still the simplest way.

Thanks for all your help.
 
Last edited:
@Lindon: if 1=1: Could you please elaborate? I used to know but I forgot what it is. I often comment out parts of the code to see how it goes, and I suppose if 1=1 is a similar technique?

Well you dont seem to need it in this case but just in case you do at some future point...

so the KSP parser will barf when there are too many lines of code in the INIT call back...a way around this is to place some of your code inside an if statement (which the parser doesnt mind - really go figure that out..)

So you end up with this sort of thing in your init

if (1=1)
(some declaration code etc in here)
end if


But as I say it would seem that is not your problem right now. - sounds like its really a design issue.....
 
Well you dont seem to need it in this case but just in case you do at some future point...

so the KSP parser will barf when there are too many lines of code in the INIT call back...a way around this is to place some of your code inside an if statement (which the parser doesnt mind - really go figure that out..)

So you end up with this sort of thing in your init

if (1=1)
(some declaration code etc in here)
end if
So you're saying placing parts of the script inside if (1=1) statements probably makes it create more but smaller stacks internally?
 
Last edited:
Check this link out:
Very clear, thanks !!!

So I tried splicing the ICB into if (1=1) statements that are shorter than 900 lines (which I didn't do before). And... It made a difference: Now there's no more stack overflow, but the first bug (the one I wrote about in the opening of this thread) is back! The way I got rid of that bug the first time was by upgrading from K5.7 to 5.8, so... I guess I'll try 6.2?

Fortunately, these issues only arise when I increase arrays sizes past my present needs - but by just a tad!
So, threading so close to a breaking point still worries me.

Note that my ICB doesn't get near the 11000 lines limit. But the whole script is now 13000 lines and still needs to get much bigger. Should that worry me as well?

One more question: does anyone know if Kontakt's parser scales its capabilities to the computer's capabilities? Because I'm working in a virtual machine. I find that more comfortable, as long as I don't need to output actual sound (and for now I'm just working on the UI). I don't suppose this could be the cause to my problems?
(Note that the virtual machine has 16Gb of virtual RAM. But of course it is still slow compared to actual hardware.)
 
Last edited:
does anyone know if Kontakt's parser scales its capabilities to the computer's capabilities?

I don't think it does. Parser stack is likely a fixed size. 16 GB of virtual RAM is still plenty, but it is of no consequence when we don't know how big KSP parser stack is.

I would really like to check the script out, you must be doing something weird in there...
 
Top Bottom