error: "coll cannot clear in response to a dump please use deferlow"
Hi, I'm trying to get some info on this error message I received:
"coll cannot clear in response to a dump please use deferlow"
I can't find it in the documentation or the forums. What is the behaviour that causes this error to be thrown to the max window?
The patch is not triggering a clear message to coll via its dump bang outlet, which is my best guess about what this error is describing.
it is regularly dumping the coll contents after adding data, and clearing the coll data on a timer, so I guess clear could be triggered while the contents are being dumped if that's a time-consuming operation.
How would I use deferlow in this case? just after the clear message?
thanks
I've never heard of this error. And I definitely have been using code which literally clears a coll in response to a dump, kinda like what you say is your best guess. I'm interested to see what turns out to be the culprit here...
(using Max 8.6.2 right now, btw)
How would I use deferlow in this case? just after the clear message?
yep, IF that would have been the reason, that´s how you use defer and deferlow.
behind them we´re in another thread and or have other queue rules, similar to how you jump to the higher thread when a toggle triggers a metro or line.
Thanks Roman and Tyler.
It's code that's been running on a public installation for months, and this is the first time this error was thrown, so I was assuming I would have a lot of trouble reproducing it, but it was easy:
without the deferlow, it throws the error, but with deferlow, no error.
the only problem for me is my clear message is totally independent of my dump message, and I can't recreate the error without triggering clear directly via coll's left output. Maybe it's a timing problem that only shows up when the computer is under heavy usage. Hoping deferlow solves my problem anyway.
the “dump is done” notification bang comes out the right outlet. In your case, without the deferlow you’d be calling clear after every element output by the dump. It’s a little less surprising that would cause errors because you’d be trying to clear the coll in the middle of the dump operation (1000 times…).
it´s good that you isolated the problem for this thread, but this problem is a bit different from what we thought (insert here everything what tyler said - you probably want to experiment with the 4th oulet now)
yet it is a perfect example when deferlow can help; at least as quick and dirty solution when something does not work and you cannot solve it otherwise.
some things will always remain hidden. for example in older versions of max, the following did not work:
it would always have only affected the rightmost subpatcher´s windowsize, no matter what you try (including deferlow.)
there is absolutly no logical explanation for that, it is as if all thispatcher objects across the runtime would share the same inlet or input buffer, which is single-client for some reason.
a fix was easy to make, but the reason is beyond me.
apropos message order.
if overdrive is not required for the output of the mechanism, this will also work:
the defer (great: now we also have a valid example when to use defer) is here only needed in case overdrive is on - and will not be in the way when not.
(it might also be required when the coll holds 25,000 entries.)
Interesting!
Though just to reiterate, that image I posted is me experimenting with creating conditions for the error message. (experiment successful!)
In the original patch that threw the error, clear is only called via occasional timed bangs, entirely independently of the dump message logic and of the coll outlets. I wasn't able to recreate the error under those conditions, even with a very long coll, so there remains a mystery.
I'll hopefully rebuild over the weekend and add deferlow. I'll update to thread if the error persists, but as it seems to be a very occasional error (twice in 48 weeks of daily operation), it'll be hard to know if it's fixed. I guess if I don't post in this thread again before 2025 it probably worked!
if your logic with that coll can afford it, disable buffer clearing while dump is in progress.
easy to do so ..