Hi CKB 
,
Ok, ok, ok. It was clear to me (i have some script topics on my watchlist 
) that your script has a reason for having over 14000 lines, but it is still just a small midi controller, even with 24 buttons and buttons just have only two states: on or off. What i am trying to say is, that a controller of this size cant create a traffic that will introduce latency. I am aware that your script must be jam-packed with a LOT of functions, no doubt, but you can only adress a limited amount simultaniously. So even if the buttons (+1 fader +1encoder) are occupied with more than triple or quadriple functions, you cant use them all at the same time. So at the end, there will be always only 1 fader, 1 push encoder, 24 buttons and 24 LEDs for a incoming action and this circumstance will hardly introduce latency. Thats all i want to say here. 14000 lines might sound huge if latency is in question, but not for such a hardware. I am pretty sure that you have a smart hierarchy in your script, i.e. sections where Cubase (or midi-remote) will look at, if a particular condition is met. Thats how i did with my script at least, so for example: if one condition is not true, skip next 200 lines or more of code (extremely simplified 
). I hope that you (or others that read here) understand what i am trying to say here and with my last post.
I strongly believe that the script language is extremely inefficient, even if i have absolutely no clue of it. I have seen it in the past, where someone tried to write a script for my controller and had even trouble to write working code for i.e. lamps. Even button states had ridiculously long code, for being just that. The only two good things, that i have seen so far with Javascript are parsing text and the freedom to create things on your own, but thats it and how far this freedom goes, is something i dont know, because i havent seen things that have impressed me somehow, mainly because everything so far, was nothing “new”.
I will give some examples of my script:
1.) The ability to use more and new LED ring modes outside the 5 that the encoders of a MCU has to offer. For example in sync with midi-clock blinking LFO speed/rate. Like this:
2.) Level meter usage that works outside the boring, inaccurate (and stupid) Peak-level meters. I use Level meters, to effectively show how much a key-press with velocity and aftertouch are influencing a given parameter and there are 15 of them for a A-Station. All of them accurate and simultaniously shown. A fact, that no MCU (or MCU based device) is capable of (8 is max) and noone even has attempted such a thing AFAIK.
There will be more “fun” facts, once i am completely finished and just for the protocol, i am no coder or scripter by all means. All of this might sound harsh, but if you really have the freedom to do “anything” with Javascript, why i dont see more and “new” creativity and features with it? It seems to me that exactly this creativity is lost, because you are occupied with tremendous afford and work to get the simplest things done.
Still great props for your script (and the 3 or 4 other people) that indeed has a great amount of functionality. I use only 4 mapping pages so far, but that are still over 120 parameters/ options and use nearly the same amount of custom variables (240 or something). As a note, my script runs outside of Cubase and has no latency. I will make some tests, what happens if i record/play automation of 32 parameters at once, that would be a lot to process and will look like a freaking disco show, with all the LED rings going crazy . Maybe not possible, but i will try.
Cheers u-man 
