Guidance request on how to dynamically adjust zone numbers in display at run time

[RalphBacon]

Subject of the issue

Guidance request on how to dynamically adjust zone numbers in display at run time

Your Environment

Library Version: 3.6.1 Arduino IDE version: Using PlatformIO (Visual Studio Code) Host OS and Version: Windows 11 CPU Hardware model/type: Intel Core-i5-12600K

Steps to Reproduce

I'm trying to dynamically adjust the display to contain either 1 zone (all modules) or 3 zones (split). If I use begin(1) and begin(3) it all seems to work but there is a memory leak and eventually crashes. I suspect I should not use begin(x) more than once; or I need a new function to delete/release each zone buffer?

If I initially create 3 zones [begin(3)] and then use MD_Parola::displayClear before resizing the display from 3 small zones to one large zone (and vice versa) it only seems to recognise the 3 zones; displayClear doesn't seem to be the correct method to reset/clear my display zones.

Can you let me know how to dynamically resize the zone(s) in the display at turn-time please? Or let me know where I should put a new function to release the zone buffer(s) to stop the memory leak I mentioned?

Expected Behaviour

Zones should be allowed to be dynamically reset/resized.

Actual Behaviour

Memory leak (about 1k memory per iteration between 3 zones and 1 zone using begin(x))

Code Demonstrating the Issue

I can supply a cut down version if you need it. BTW this is an amazing bit of work, thank you so much.

[RalphBacon]

Update:

I have "solved" the "memory leak" issue by breaking one of your MD_Parola rules.

If I declare 3 zones, but set two to just a single (overlapping) unit, with the third to the full display

setZone(1,0,0); 
setZone(2,0,0);
setZone(0,0,27);

I find that I can use Zone 0 for the FULL display (no corruption).

When I want to use 3 zones I can respecify the zones:

setZone(1,9,17); 
setZone(2,18,27);
setZone(0,0,8);

and this is honoured without corruption nor memory leaks.

As I say, this does break your rule that zones must not be overlapping but if I do not use two of the three overlapping zones then nothing bad seems to happen.

A bit of a "workaround", your thoughts appreciated.

[MajicDesigns]

begin() sets the number of zones, or in your case the MAXIMUM number of zones that the library needs to be able to handle.

The variation in zone size is handled using setZone() as per your 'workaround'. The reason for not having overlapping zones is that the animations will get screwed up. If you are not using 2 of the 3 zones than there is no issue.