live.object replace_selected_notes bug?

[jay.hardesty]

(This is a replacement for an earlier post udpreceive/live.object problem with a more general description and simpler patch)

The patch below replaces the notes in a selected MIDI clip with a single note (a middle-C on the first beat). The clip must be the current selection. The following messages are sent to the same live.object in order:
goto live_set_ view detail_clip (via live.path)
call replace_selected_notes
call notes 1
call call note 60 0. 0.5 80 0
call done

If I manually trigger the patch by clicking on the top, leftmost button, then everything works fine - the clip gets populated with that single note.

But if I use any of the other triggers for the patch:
1. a delayed bang (initiated by a manually clicked button)
2. a bang triggered by a notein (or midiin)
3. a bang triggered by a udpreceive object
then no note appears, and the following appears in the Max window:
live.object: 'MxDCore' object has no attribute '_throw'
live.object: 'MxDCore' object has no attribute '_throw'
live.object: 'MxDCore' object has no attribute '_throw'

I've verified that delayed bangs, midiin, and udpreceive each work fine in conjunction with other calls to live.object, for instance with get_selected_notes.
Superficially the difference is that get_selected_notes is a single call, whereas replace_all_notes is part of a sequence of calls. Is there some restriction on how such call sequences can be triggered, or is this a bug?

Live 8.1b8 / Max 5.1.0b8 / Mac Pro - OS 10.6.1

Thanks,
Jay

<pre><code>
----------begin_max5_patcher----------
907.3ocyX1sbhBCEG+Z8o3Lbi235j.DD161t6s6SP6NNQHUyVj3.wZ61ou6a
BfUrsHAKxvLZ.iPx+767QNvKiGYsT7DKyB9NbKLZzKiGMJuKcGiJ+8HqMzmB
ioY4WlUnXyFVhzZZw+IYOIy6+G.rjlrB1KReHaJvuGjo7UqXorHX4y.E1PS1
QigvXd3CGt6sorL0fQkbQxhTVnrPItjYnoks1D+7CnYH3Ok2VxtM7jXlLWQ3
xN4Q45Pr7ueCiNLA2KRjIzMrBIlxowVGGCwN4gAAcPPTY3ZdxpVHlpqgp5QO
0Y7+kO0X6YHcuuNdrtY5Wj02rSBx0poEXzv0PHcm5z6rl76m90OEorIfBBJ8
CqoYPh.nRkoX4NIClrPtNUrexcV.KMUjl0fgvwCcbw6D30ZKQPGZHZTLWQKg
hdR0fddZ4Yaq0j2bcKprwXT4+4.AWOP7JPAFQNfh2AjhgQ97VVwMXoiPsf+b
A.HgsWIxO3ItKRwhPF+QFPbQnl.Tgfmm2FDzZuo4s0apY3UqVpyY5CL05sao
C7ypAyIBIi2j6GAiNthbaerpWaoqS8zsIsXLc45zembnKwsQg0DaWs9IWVXM
o0dlkrqWBqMB.XuJgJehdZBAtsFAMMiF69bkIiy7uFYraMYZZF6AxTSNpHVL
8YfbbSfSV71eRUZcX17RrTFy34XbLyUO0crZuwYE0iYJXbbqmLvMh3n1iGTY
oSUxJi8qfmPQrHs3ZQyB7ccvt5zb93.OjedBOBJPcB9bHsFbh5bbpVgqsLLD
yw4hf441aytnBzhxQI3qDLmV9sKg5FVVFcE6CTMjFGCQhDlwtn1csKZYnqiS
AUKbQ85M2s5HyJgT.ZmtEYLI7HmsGhXRJOdg5AY2ZLtvcMtN3DVfKrq+.gW4
dRorswzPMxhUBlEsPW+ZlovxNnyS+M+TX4zyv5zZIZrn.uKM+tsK55Wx3Ys7
4FZ.arolbk1oqzT6QFRgEZ3.dH0F.pODvWclwfpySff8qBJLtqHU90n1lN48
uVwbMn6+T7kI1kFdXFJqIFNJhHVljm7V4r29VoiUtl07nHVR02dzFdzVg5gE
KkPM94lpHrAJRGz1iRZtARxuWUj+vCRdFHIRupHxvCRtCOIYahgyoeyAXaRR
.G29USjAnlLw1oqvavoIx.TS3AXbmcupIG6AnOdvvSS5WygYZB2eZxnblNeA
No9wqi+Os4rIGB
-----------end_max5_patcher-----------
</code></pre>

[pukunui]

Hi Jay,

Thanks for the clear report.

Calls to live.path cannot be relied upon to return like normal max objects.

The button press works because it runs at a lower priority then the other events in the patch, you can see this if you defer the rest of them.

Or you could patch it like this

Welcome to the brave new world....

-A

<pre><code>
----------begin_max5_patcher----------
853.3ocyXt0bhCBEG+Y8SASd10ABPjrus6WiNcbhIrV1IBNFrW1N869xknlZ
MMWZL0QMjbPg+meb3.3qSmDrR8LuH.7SvcfISdc5jINSVCSJedRvljmSySJb
es.I+I0p+FLyWkl+r1YVCVU9J+Pc+QI0xjMbW8+ZmHIG7aUd1gpk62Hj4bsq
YQkF2lnSePHWubGOU6kEFQmCmAvjPaAE5JPr4Pv8mZI0d8glhVZUj45XiX+Q
HrplJD+yoIDzzRdy9et9ksbeeFrJQtNXV8kAf6s+x2lN0dYVKY2p8ZsR1Y.v
hc..53PH7v0Z7ezG8eTbvm5ninyPhV3G+H80YXWAeolf58YaMJmKdjCnD3wf
HiwBtTmnEJYEWKJx4Mw9qwevy937g9BOJolt3xvqpdqApzKNAIr9IHCJmkJM
WHa.uzP5I7RhtF3EFWAuWnKdOdwsGuHTW4qPps4YpTLlSRKAQ+mjhBu5YbpI
LAwpLK7xRucYcgQdFzsrtsIX.+cwFb7.wFrmMzgmMjwK6dFOO4EyFJfAcKCR
XyfwGzDg6wDmNmIdv4RtY8t4lJrdUO1J2mfGJ1m7lxrEKnMrStKfGLoq6jK3
XimpxU67VgyiYDLhLybGCEGAY16fTXr4FjUPCLNMv3gqz9hQ98EiZ.l3K.Sb
mg4rxOiFT2vKJRVy+.USSxyAYJIefCQwH2LX7B2Jf9DbVScHDMrGgnCHYVqz
JfMnaYAWCdTveBjw0Ih7ko4hsCNt7KAv7mJiv5AuPeu7xEIsiuMOI0hrbiuw
yVZ2RZw.CqH5BerkmRDb2gUX73.qddR0xnAZ+OoZzUX8+Ocj2MPCPC8JckC0
L2XbTORifVbCLsvBGPDzjF27lBXl6FXPQvUy2hP8fTgewDHtdxrLs77+HLmb
s1eO9JT62kdnoN72KANI3LdgVHOtK26NsrPkuzChrLtq9CpbiHaqxbPuRQTy
fYmzDpAMYI2XqovFzjMter0DtINEO9ZhzT7D4cCvMpIFbwbpoYIw1BZL83Se
Q0Z2EYiQ+mME4ZSP6wHaTS1iZMlZh1FMEMpZpMRhMpJhc6AIDpMZZbSueV2c
avI7MnlhZyRyi7xfsIdBSFWNs31SS3vaOMc1NAtM3TqhmveAMYd3so+GBdc7
uB
-----------end_max5_patcher-----------
</code></pre>

[jay.hardesty]

I see - yes, a deferlow object straightened everything out.

Another false alarm - sorry, realize this list isn't meant for support... now hoping to find an actual bug!

Thanks again,
Jay