LUA memory leak issue?

[TK.]

Hi,

while working on a new panel for my MIDIbox FM I noticed that Ctrlr dramatically slows down than more often patches are received (size: 268 bytes).
To be more exact: after Ctrlr startup the GUI will be updated immediately on a received patch, after 10 received patches the GUI needs ca. 1 second to update all components, after 20 received patches more than 2 seconds, etc… after the update the GUI is fast (as usual) again.
It looks a bit like a memory leak issue, but I’m out of ideas how to debug this.

The current version can be downloaded from this link: http://www.ucapps.de/midibox_fm/midibox … _panel.zip

The MIDI receive handler is based on the Novation A Station panel from Widy – basically it stores incoming SysEx streams into the global variable "full_mem_block", and the extracted patch into "mem_block" before values will be distributed to the modulators. I guess that LUA should do the memory allocation/deallocation handling by itself, right?

Other informations which could be relevant: I’m working under MacOS 10.7, the issue happens with the standalone and AU version of r947

Best Regards, Thorsten.

P.S.: except for this issue I’m very happy with Ctrlr – I especially like the scripting capabilities, they give me exactly the flexibility that I need for my purposes! ” title=”Smile” />

[atom]

I’ll have a look at that asap but even with a 100 received patches this will be about 2kbytes of data and that’s not big enough to cause that much problems.

[TK.]

Thank you for looking into this! ” title=”Smile” />

I just tried the most recent r965 build, but it seems that the Lua scripts are not called anymore, therefore I’m unable to check for improvements.

Best Regards, Thorsten.

[atom]

No scripts are called at all or just a specific event isn’t getting triggered ?

[TK.]

No script is triggered anymore.

You can reproduce this by clicking on the "Receive" button of my panel – the MIDI event will be sent (because I forgot to disable it), but the requestDump script won’t be executed.

Another example: receiveMIDI isn’t called as well.

Best Regards, Thorsten.

[atom]

yeah i fucked up the negative mapping of parameters and that broke some stuff, i’ll fix that asap, and re-upload the new build

[TK.]

I found the "leak": it’s not Lua itself, but the Console window.
Than more messages are print, than slower the GUI.

I had a similar issue in an own Juce based application a while ago, and solved this by overloading the ListBox class:
http://svnmios.midibox.org/filedetails. … LogBox.cpp

In difference to ListBox, it doesn’t store the text in a (huge) string, but stores each line in an array: Array<std::pair<Colour, String> > logEntries;
This allows to log thousands of messages without affecting the GUI performance. ” title=”Smile” />

I would recommend to use this method for the MIDI monitor and the Lua Console

Best Regards, Thorsten.

[atom]

The MIDI monitor is actually buffered (the buffer size can be adjusted in the main preferences) i just forgot to add it to the console, i’ll do that asap.

[Author]

Posts