Is there a limit to how large a MIDI Remote script can be?
For example, are more than 10,000 lines of code a problem?
What else could the size of a MIDI Remote script depend on?
Hi,
Iām not aware of any limit.
More Faderport features?
of course 
1 Like
I didnāt find a limit (yet) concerning the file size or number of files.
But, i managed to overflow the MIDI protocol by trying to use about 50 controls plus various callbacks per track (8 tracks per port).
When banking, i would take a few seconds to update everything. So iām currently trying to implement a mechanic that would send only priority infos and then wait for the right moment to update the remaining parameters.
Iām not sure that i will succed thoughā¦
Thomas
Hi,
You are right, the MIDI protocol speed might be the bottleneck.
I would suggest that you open a new thread for this, itās very interesting and can be successfully approached.
No.
Itās more about the integrity. It all comes down to the pressure the compiler receives and if it reaches a timeOut. In some scripts here, around 1mb, no problem appeared.
1 Like
I will certainly do once i get some progress on this but iām also having some bandwidth overflow these days. 
1 Like
I do this so that everything runs as quickly as possible:
When programming, I make sure that in all callback functions the relevant code is only executed when it is really necessary.
I also avoid any redundancy when sending MIDI commands. For example, I have built a VU Meter that transforms fader values into 10 different colors and sends them to a controller, that has only simple LEDs. The script is programmed in such a way that buffering is performed and the MIDI commands for the colors are only sent when the color has actually changed.
Ergo: You have to write a real program that goes far beyond what a script is. JavaScript provides this option.
My controller only has one fader, one rotate knob and 24 buttons and I have now reached 8235 lines of code.
Here a report from my actual experience:
My current script update, which I have not yet published,
now has 11.868 lines of code and is 1.132 KBytes in size.
I have no problems with the size.
I also donāt have the impression that anything has slowed down.
Only the loading of the script takes a little longer, of course.
A reload within Cubase takes about 4 seconds on my laptop (not a high-end device).
This is pretty fast actually. Here it takes more than 8 seconds to reload. Note that upon reload all scripts are actually reloaded not just the one in use.
Is there a way to completely remove the factory scripts that are of no interest? Removing the files doesnāt seem to work as they get recreated upon launch.
Exactly.
Well, we can always remove them from the factory folder:
C:\Program Files\Steinberg\Cubase 13\midiremote_factory_scripts\Public
Not sure if this could bring up any implications, but I donāt think so.
2 Likes
Thanks, that was it.
Didnāt even realize that folder existed.
1 Like
I am currently testing the upcoming (not yet published) update of my MIDI Remote Script.
It now has 13265 lines and is 1280 KBytes in size.
I still have no problems with the size and the loading times are still quite short.
This means that Steinberg has done a good job in this respect.
3 Likes
Most credits go to https://duktape.org/ 
3 Likes
Update on this topic:
The current version of the MIDI Remote Script I published here in the forum for the
PreSonus FaderPort (Version 2018 with one fader)
has now 14,929 lines and 1,453 KBytes in size.
There are no latency problems when using the script
and the time for (re)loading the script is acceptable at around 6 seconds.
Best regards
CKB (Christian) 
I really, really respect your work, so please dont be offended. Its a small Faderport, with no display, no encoders, no LED rings. I expect no latency for that case. How can latency even occur here? ā serious question.
Over 14000 lines of codeā¦ impressive, but here is some comparison:
I am doing a midi remote panel for my A-Station with a Mackie C4. I use Bome MTP for this. I have over 120 bi-directional parameters for at least 32 encoders with LED rings, four displays and 19 buttons, have a paging system and have less than 1400 lines of code. It would be far more less, if i leave out any comments and most of the lines goes out for printing description and values to displays. ASCII conversion, where every single letter eats one line. Loading time is instant and the project eats up 220kb so far.
1 Like
Hi u-man,
the FaderPort has only 1 fader, 1 push encoder, 24 buttons and 24 LEDs. Because there are so few control elements, but over 400 functions are realized with the script, the script is about 15,000 lines long.
In my script there are 11 mapping pages, 35 subpages, 250 custom variables, 150 callback functions and an extremely large number of internal variables and help functions. Many functions are synchronized with several mapping pages.
When I try to add debugging commands to all callbacks and functions and work a little with the script, countless messages race across the console window. Of course, what I see there is not all MIDI traffic, but I think it is generally interesting to see whether latency can be the result of a huge complexity like my code.
Note: A MIDI remote script runs in Cubase in an internal interpreter and in parallel within a real-time application. The interpreter is a black box and up to now it was not certain whether buffering or something similar would take place above a certain code size. This means that a latency could at least have been probable. Fortunately, this is most likely not the case.
And thatās exactly what I wanted to make clear with my post: That the size of the script doesnāt matter, except for load times, and all you really need to focus on is keeping MIDI traffic between Cubase and the controller to a minimum.
Best regards, also with great resepct for the work on your script
CKB 
1 Like