time for if 1=1 in the init...
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.I don't see it.
Are you suggesting load_array() ? So I would need a temp. script to save the array first as well?@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).
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 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.
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.
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.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.
Would you educate me as to what initializers are ?specially string arrays which don't support initializers... :(
Once again, I'm not sure what you mean.You can create the scripts externally, no need to use a secondary script to generate them
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)
Once again, I'm not sure what you mean.
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 )Constants, variables and arrays can be initialized, aka declared and assigned a value in one line.
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.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).
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 !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 !
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
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.
I get it. It's super simple!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.
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
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.I wonder what you're doing over there.
So you're saying placing parts of the script inside if (1=1) statements probably makes it create more but smaller stacks internally?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
(some declaration code etc in here)
Check this link out:So you're saying placing parts of the script inside if (1=1) statements probably makes it create more but smaller stacks internally?
Very clear, thanks !!!Check this link out:
does anyone know if Kontakt's parser scales its capabilities to the computer's capabilities?