System-load increases with count and/or effort of modes

Hello I found that the count of modes affects the performance of the ETC system directly.
Also it seems that the complexity of the modes affects the performance.

My test was a very simple mode that does some automatic movement of one circle. The movement is normally smooth, but becomes stuttering the more modes are in the /usbdrive/Modes folder. It is not noticable yet at ~70 modes, but becomes annoying if we are above 200 modes (for my test these where copies of the same simple moving circle).

The next test was using a mode which causes more effort to python. I used a mode which draws 1080 circles (, and lets them move around, so they look like kind of tubes or soap-bubbles. There I found that already 60 copies of this mode cause the stuttering.

I connected to the ETC with ssh and checked the output of top, and found, that the average load with a smooth moving system is around 0.60, but under the testing conditions mentioned above the load increases up to 1.40.

So it looks like the code for all modes is executed all the time, but only the actually selected mode is executed to the display. Is this right?

If yes, do we have a chance to change to some kind of “execute only the code with is sent to the display”?

Best regards

no thats incorrect, it only renders the current mode
(you can see that in the main while loop calls mode.draw(), where mode is set when you change modes)

the main issue with lots of modes, is that resources for all modes loaded into memory, (*)
and there is not that much memory - so I’d hazard a guess, if your seeing issues,
its probably that memory is low, and its starting to page.

(*) this is so that you can instantly switch, overwise when you switch you’d potentially have to wait for a bitmap or something to load into memory.

If you kept presently unused modes in a burner folder, with a different name - i think that might help. Are you using 200+ modes in performance?
If not, you could shift the files around depending on what you’re working with at the time.

I rechecked, but unfortunately memory is not an issue (I don’t use images for this test).

Regarding the unused modes: It is not about unused modes. I am planning a show (it will be while the Superbooth in Berlin), where I have ten or twenty variations of a mode, and I switch between them sending PrgChange commands from a sequencer.
Instead I could expand the midi control to all 127 controllers and create the variations by the controllers within one mode, but then the modes would be incompatible to the standard ETC. That’s what I wanted to avoid.

A workaround would be to use a mor powerful linux laptop instead of the ETC, but I like having this little box.

hmm, what kind of framerate you seeing?
hard to say, but none of this is preemptive, so could be lagging, or even python/pygame doing something like gc…

but its definitely not rendering other modes, ive had really heavy modes whichalmost kill it, then switch to next mode, and all is fine.