live.path this_device sometimes reports "id 0" on initialization ??


    Jul 05 2019 | 4:56 pm
    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.