What's new

KSP: any insight into this mysterious bug?

Fredeke

Senior Member
Hi
After some code rewrite that didn't significantly alter the overall structure, a bug appeared that just blows my mind.

The precompiler precompiles without error (finally ;)), but then Kontakt (5.7) refuses to apply the script because this generated line:
Code:
set_control_par_str(get_ui_id($mn_tk6_select),$CONTROL_PAR_TEXT,!_track_name[20*99*$act_page+(20*$act_drone)+19])
returns this error: "$mn_tk6_select" was not declared or is not allowed here.

Needless to say, when parsing the generated ICB, I can see that control is actually declared. And as for it not being allowed "here", well... It's just in a UI callback.

But it gets weirder: When I deleted the whole portion of script generating that callback (it was a macro iterating other macros, generating a bunch of callbacks, for a bunch of buttons), the bug migrated to a seemingly random but similar line, regarding another ui control, this time not in a callback but in a function (so what exactly is that "here" where perfectly normal commands are not allowed anymore?). I repeated the operation of deleting one problematic section after another, and the error keeps moving seemingly randomly from one set_control_par command to another - each time related to a completely different ui control - of any kind, apparently - and in no apparent order - and without apparent relation... not apparent to me anyway.

Btw, the parts generating errors are not the ones I rewrote since the script worked. I know SublimeKSP sometimes "displaces" errors while doing its magic, but this time I really don't know where to look for the cause.

It may be worth mentioning that, while the SKSP script is still compact enough, the generated KSP is thousands of lines long. I rely a lot on iterating macros, because I see no way around that: I need to change the content of some menus on the fly, and since Kontakt doesn't do that, I need to emulate my own menus using a lot of buttons (don't I?). So there are hundreds of ui controls in my instrument, even though most are hidden most of the time.

Besides so many controls, the script also deals with a dozen of hundreds-to-thousands-elements arrays. They act as a "databasesque" configuration for the instrument. (See the last argument of the command hereabove)

So, first and obvious question:
Is Kontakt's script interpreter known to break down under such a load?
Or is it just my brain, breaking down under the unexpectedly growing complexity of this undertaking?

Then:
Experienced KSP coders, what do you think?
Ever been confronted to a similar issue?

I hate to admit I may have bitten more than I can chew in terms of complexity. But I still hope a simple hint could help me get unstuck.

[UPDATE: I just deleted all set_control_par commands, and now other (completely innocent-looking) occurences of those controls are generating errors because they're allegedly not declared - when they clearly are. But it doesn't say anything about them being "not allowed here"... So this narrows it down a bit I guess?]
 
Last edited:

EvilDragon

KSP Wizard
This is gonna be hard to figure out without the actual full script being posted... It could simply be a typo somewhere...
 
OP
Fredeke

Fredeke

Senior Member
Thread starter
  • Thread Starter
  • Thread Starter
  • #3
Yeah... I won't inflict that on you.

Just been messing around for the last hour and will continue to do so for as long as it takes I guess.
:shocked:
 

P.N.

Senior Member
This happens in 5.7 only?
Does it work in other versions? The reason i'm asking this is because, in my experience, 5.7 was notorious for having some unpredictable bugs.
 
OP
Fredeke

Fredeke

Senior Member
Thread starter
  • Thread Starter
  • Thread Starter
  • #5
It's the kind of issue I've run into when using ui or variable prefixes ($,@,~,% etc.) when I shouldn't (according to the SublimeKSP doc), or not using them when I should (according to empiric trial and error), or that kind of shinanigans. But usually I got that quite quickly. Here, I don't see it.
 
OP
Fredeke

Fredeke

Senior Member
Thread starter
  • Thread Starter
  • Thread Starter
  • #6
This happens in 5.7 only?
Does it work in other versions? The reason i'm asking this is because, in my experience, 5.7 was notorious for having some unpredictable bugs.
Waw. In such case, I should upgrade before wasting more time.
Anybody else thinks it could be 5.7's fault instead of mine?

I can't test it right now because the only other version I've got lying around is 5.2, which lacks key features I need here (like real arithmetic). I've been meaning to upgrade to 6 soon, but was hoping to still dev this one for 5.

PS: I like your avatar. Did you change it?
 
OP
Fredeke

Fredeke

Senior Member
Thread starter
  • Thread Starter
  • Thread Starter
  • #8
Send me the code then, so i can steal it. I mean, test it.
Seriously??? If you mean that, I sure would.

Even though you're kidding about it, I wouldn't mind you stealing a few of my ideas (would you find them worthy), after all you've helped me for the past year.

Let me prepare a zip, and I'll PM you soon.

@EvilDragon: As soon as I find an opportunity, I hope I can repay you too :)
 
Last edited:

P.N.

Senior Member
Yeah, i'm not gonna steal it. :D

I'm just gonna paste it in 5.8 and 6 to see if Kontakt eats it.
I mean, that's all i can do...

You can send me the compiled code, with compacted variables. That shouldn't matter.

PS: No, same avatar. :)
 
OP
Fredeke

Fredeke

Senior Member
Thread starter
  • Thread Starter
  • Thread Starter
  • #11
Ok, just to let everyone know: @P.N. and I determined version 5.7 was at fault. Version 5.8 accepts the exact same script without the slightest error. I guess this settles that, and "all" I've got to do is upgrade.

Thanks.
 
OP
Fredeke

Fredeke

Senior Member
Thread starter
  • Thread Starter
  • Thread Starter
  • #13
Could it be you used arrays larger than 32768? This only works properly in 5.8+
That could very well be it!
I overlooked that limitation, and indeed some of my multidim' arrays can grow beyond it.

Out of curiosity: From your phrasing, I get that this is not an official limitation of 5.7 (which would yield a clear and relevant error message), but rather a bug in handling huge arrays?
 

Lindon

VST/AU Developer
(snip)

Out of curiosity: From your phrasing, I get that this is not an official limitation of 5.7 (which would yield a clear and relevant error message), but rather a bug in handling huge arrays?

Nope, thats been a documented limitation in Kontakt right up to 5.8
 

EvilDragon

KSP Wizard
Array size limitation grew with time. Initially I think it was just 1024 or so entries (in Kontakt 2), in Kontakt 3.5 this limit was increased to 2048, in Kontakt 4.0 it was increased to 32768 and it stayed this way until 5.8, when they increased it to 1 million finally.
 
OP
Fredeke

Fredeke

Senior Member
Thread starter
  • Thread Starter
  • Thread Starter
  • #18
Ok now I have another problem, and there's a chance it belongs in this thread:

Kontakt 5.8 (working with the demo for now) displays this error message for seemingly random lines: parser stack overflow.

What triggers it is the size of arrays: past a certain size, I get that. But no array exceeds (or even approaches) 1 million elements. [UPDATE: it seems it always happens on a line involving an array, but sometimes it's just, like, the 2nd element of a 10-element array]

What does the error mean exactly? I mean: does it mean there are too many variables, or that the script is too long, or... what? (Should I try K6.2? Is there an already sufficient market for K6 instruments?)

(I haven't even really started coding the instrument's engine. I'm only dealing with the interface for now. If the script is already too much for Kontakt, maybe I should just drop the project and accept it's not suitable for Kontakt? Does that happen to people often?)
 
Last edited:

d.healey

Senior Member
Does that happen to people often?
Newbies often have such id10t errors :P

But seriously just post your entire UI code. I find the most common cause with these kind of issues is the developer over complicating their work in an effort to make it easier to maintain and be more reusable. It sounds counter intuative but I find myself doing it often. Sometimes the simplest verbose code is better than the more complicated but leaner version.
 
Top Bottom