Hi all, I'm wondering if anyone else has encountered this bug. I've run into it quite a few times in my M4L developments in the last couple weeks, in multiple different devices.

The problem, on the surface, is quite simple:

[live.thisdevice] | [live.path this_device] | < do stuff assuming valid/unique id >

Sometimes, and only sometimes, the output of [live.path this_device] is "id 0" which is clearly bogus. All I've been able to do is, in a couple of key places where I use this construct, put in some safety checks against getting "id 0", print that something was wrong and then retry to get a valid id. Even just retrying after a [deferlow] seems to fix it, so conceivably I could put the [deferlow] after the [live.thisdevice] and maybe never see this issue again. But it's a simple bit of code so it's not in an abstraction and it would mean some unpleasant auditing tasks are in my future for other similar usages.

But this is also a seemingly very basic setup that, unless I'm mistaken, should reliably work without any retries or [defer] workarounds. Am I wrong there?

MORE INFO

I made a very simple test device to try reproducing this problem a few weeks ago and it did not reproduce, but I've now seen it a couple times in some larger M4L devices which have way more things to initialize.

Max version 8.06 -- I first saw this while I was running 8.05, but saw that 8.06 had some possibly-related changes ("live.path: outputs properly when in a subpatcher that is in a poly~"), but I started seeing the issue again this morning. Live version 10.1 -- I don't recall ever seeing this prior to Live 10.1.