Noah Neumark

I have a very complex Max for Live device I'm working on with at least 5 levels of nested abstractions, and one of the third level abstractions has a pattrstorage object to control settings on that level. All my UI control objects have a trigger that first sets values within the algorithm, and then bangs out the algorithm. This works great for general use, but when loading the device and changing presets, it generates a lot of redundancy because every UI object triggers the full algorithm. I've added a method of filtering out redundancy using a gate that is initially closed, and then only opens when a loadbang fires on the main level, which should fire after all the patches and subpatches are finished loading. I'm also using this gate such that it closes during a preset change.

My problem is that in my complex patch (not the one below) the loadbang on the main level opens the gate, and then lower level abstractions seem to load a second time causing the redundant triggering of the algorithm. This causes significant load time and CPU drain due to it running the algorithm for each UI object in the patch.

I haven't been able to replicate this problem in a smaller patch, but i'm including this example for reference.

loadbang

print

gate

preset

message

pattrstorage

autopattr

outlet

join

inlet

live.numbox

bpatcher

I haven't been able to replicate this problem in a smaller patch, but i'm including this example for reference. 

I have a very complex Max for Live device I'm working on with at least 5 levels of nested abstractions, and one of the third level ... 

nested-abstractions-load-a-second-time-after-main-patch-finishes-loading

Loadbang? Don’t try doing anything until after a live.thisdevice fires. Pattrstorage in parameter mode won’t recall data before then. On my phone so can’t check out the patch, sorry.

In general this sounds like a good place for a delay object since it’s timer restarts with every bang in even when the delay interval hasn’t been reached, so it would coalesce all the triggering of main algo into one bang.

Loadbang?  Don’t try doing anything until after a live.thisdevice fires. Pattrstorage in parameter mode won’t recall data before then.  On my phone so can’t check out the patch, sorry.

In general this sounds like a good place for a delay object since it’s timer restarts with every bang in even when the delay interval hasn’t been reached, so it would coalesce all the triggering of main algo  into one bang.

I changed out the loadbang on the main level for a live.thisdevice, and it worked! Thank you!

I did notice that there were still some things firing after the live.thisdevice and apparently the source was a [mousefilter] that had received bangs from initialization. Mousefilter seems to release its pent up data upon completion of initialization. So I added another gate to the incoming bangs that also opens at the end of initialization, and that resolved those too!

Nested abstractions load a second time after main patch finishes loading