loadbang firing before live.xx objects are initialized?

[Mattijs]

Hi,

In the patch below, I query some info about the live set with loadbang, such as the track name. This doesn't always work. Sometimes when I load my live set, the plugins are not initialized entirely and I have to manually double-click the loadbang in order to fix this. Could it be true that the live.xx objects take some time to initialize, and might end up being initialized after loadbang?

Please let me know if you need a live set and a simpler plugin to test this, it will take me some time to create a simple set and upload it somewhere, but if that helps to isolate the problem I'll do it.

Best,
Mattijs

Code: Select all

----------begin_max5_patcher----------
2231.3oc6ckzaiajE9r7uBBcZF.2MXswk41LGx0bI2ZDXPIUsckPQJPRo1cG
j+6CqEYI1Vr3S1ROx.qCQTp3h+3W81qW04uta17EkOKqmG7eB9RvrY+0cylY
FROvL2umMec1yKyypMW17B42JW7Gyu2dpF4yMlgqJ21HCJxVK2ephsqUE4xF
ysQbC90xhlZ0OjlwneN7v01d+6uXpaT6PMeeizBv4yuu8+B9c2o2j0r7IUwi
OTIW1XuBZTX6yLfkjpODSzeRaG5k6Qsxf112fOIRleDnLHWep+akJKet9D+8
c2o+392GwzDnBTWQNQUznoE8AeLSbrgKXBC+P+rvCwDiBw7i7f+nTUbRpghi
3hkT3gIlC9kVhPRZ4W+ke48KsP5iRzOcuJPGKlL.iPQgQp2jqZB9DMH7jzBC
SkHG6PX5ChHerCGG4krMajEqBVlq1bEkZfXyklXjVhodYEARZQKBxuh1bWjU
7HXeQT.lb4rKKurVVWm8n7UDyixl98QSQSVgwMVbiLRLjjSyILbbCsoRZTgd
rroLn4IU8Cqj6TKkAKyJJKTKyxeXSVkrnwnj8PcdYKALxpZBS3MzTu5ZTbrO
mq1I+bKVexKorrLurx9RD94zDNivuu8aIjznvD82BEgosegbz6RGhLrGhj40
4OTczPtwhtW4QhGK5A+ux7UWZRs8DZf5SU8pQquO06Hi7oUJsO5LAO1bSPkb
c4N4uIWuoDtXplNYwZVLlSHwQ5uYFh4gPOaEdXAtyRLdQRS7owG4y65w+EjU
NRzwhs2fJWtSVUqJKNBsylezbqA.1YVZH0ZFmc.HsyMOlWt7OkF7DtevUxud
NOixVawGtdizTmO5dkphVq20s1lyZb.+3+tYayad3zSNcO+WyVJ68lOIMNa9
iUpUkEZPz4N0Cu+O2WBHl2W8mGvs4JJx1bhatorLeQV0NUsZQtry7PqbeVgZ
cVirQYwCM7k6SsdSkQL5nmkrHq8Y7T8xpx77NOJ6Y1chyXc78M0pVi45m0A1
pSUBNRtoiFYmw8oY1U67SAjiG+T147nl0up1vpa8pxYzxHQQmNvsWo10A+83
rc1dqY1ub+kmGUMkY8RjrQgHE1vULdYB3uJeoWkQY5jfH+QdPcdqhvkUpj5i
L6Dnhe1jjXqVQ7frYxjfMaBxeIWrdc7NRTIkBSC+kJhM9BlaWDzUMYJHY5LX
x4GB6yKcFNInyrlREhFLyU0PsXRBAZwjgnfoga5kudijBPBg6x6c+m85JlcL
.WVtdszFWz7KISXeK.YSqKUDBxcYJzWV947xdHBzbUQeAyY.k97mlEpK2Vsb
+T2d4uft.bkrtQU7R.4e4fEze5BeRsZU2.fMDsZ0lx1XKb.L32AMuct31.GB
DbGN8vMH9NYZg6Dn3NcZg6Pf3VmCvDB2m.NdjSHSGby.ha1DydRJT4D9ED2t
AaeAr01oNamb0C1xF9PVSSkZw1Fqo9N054Tk73ZUmDOmZnRz7Xd4hrbWAqd4
YL+tCrvko7fSiVWvUmuH1vct.U7wX0hbTBkM7hEQh+3rvhNZIjL75JR33sFP
+ya4JbDImM7pUPXHtbEtUjTunZAZp8g5VEw5kRcX6izJO5ZeHGIEE6y7T5s0
cDlJrqkI7uriw3K3UKaFK4L6xbwsGh4d6kjDL6OfQaI+iOhPDBuDBtMLQcqp
0nIl3ZDB6BrkD5kVnX5CrVVsSVMNdAe6Ae53SRJ6POb0ae4DdErH0WHnapJ2
HqZ9d+RaTzj1HVdIIzK6DgpR351TWFsXB5pD501DEsvyWfP34li.nFhKFcu9
wX2BWZ3vkrMRgsgjsqKeeJfbDsNMXOCB2h0kNyFKgYSclXCjhD0Sibides8O
SmjwmgSRJaLbR1q2.JZdC16jT3kcvorDqjeUVkW9swM1cVxv6V.BpAMrqLe6
5QKrAgiJnF4kTukRfIPkXFysQgauHwr6hBuRKL9Gqnor5QQPhkBmfolFqXPZ
rK9aNfkLH5VgfGjIcd18WIXJhEjaxnAtmfBYCqCRS9Xr5T64Da.O9WdJ5sZh
Or4LWLit8Fl2j7XjaY4cfwnI.xxiQ+.Z2xEqIn5vPI2zQGRGUXixfHnCqiRR
lR5nAqUOKq1e1tY.oazmkkasMOIcjTl2Ss1dRm3Vgv3djUCuUyFPwHu2.fci
y4ulMDxXTylcY4aGsXX1SOVosjXuzi315ncOnJ9.pBgjQYYz1jm8cMj0ai8G
TEqjOOZ+SAfkp3tsHoeQO5GwBd.JpEwEVqryda3zjvI2SC8+ZHHhSueF57Z7
hs2i2GC+KUQy+13V219SWRyLkYqryGWsx8AcZ1XBNxeOLbK+wAs8xoG0aZCr
Fg2Re7.gQ4.xdjeNdqLOftayHKA9ysUuiFeU6zqav4CcIeesRe2K5UsQ+oag
9WMoBESDF.LQQFSw.vzOA7qNl3PvTL9Xh.gmHngIPScbTooT.PB4IN.Hhgq7
MGBKQPERBHlK0wPiIMAYpSmCDhpb+DE3ASHxSg.vDeDjmFxbIGWdh.RFGWdh
BYtijfKl.o2IvGSCIOQQVdJAp7Dd1mnI.3IFt1woP3IZJpXhAwNNCWaALH5c
zXbkmRghIDkmfD2qtaUvbtCRpchyzlIKRuwLsUB9v2uDHcPKomoGGAQitDgA
iwo6+AFjJk7lH0P8mhHw9e7diACBRwM6PHyy35DGzzIt4qBIjPbQDErnzDy5
F6sqGFGkdgzCYQPPZ3jSrmgq6JNTVBwLqAUnFjy5.jEKbEl.krOxEpAR.9bj
CRDhg.9YFliKzFtcY4S4u7i2KABIhVAtYivoWgI0Dqgdtvbv5Bv7i26r8U.q
wWIrxDWAv5hj8hCVBH0HjKeNjHaSP04EGjOdbs.xfXTA4JKBROEWe7bPUEF2
vyhffIAtXR.JxZjydKFRsLn3iog3IbK1ofN8hOiwmdXR++vsFtjIi.lFzT.t
h3DP4ffq4IHofHv0amHApU72ZfJs+3uu6+6FQy+G
-----------end_max5_patcher-----------

[Mattijs]

such as the track name.

Ok, I can be more specific now. Querying a track name on load indeed seems to be a problem. When I load the device below in live, it doesn't put the track name in the message box, as I believe it is supposed to do.

So here are steps to reproduce:
1) open the patch below as a device in Live, the track name is not displayed in the lowest message box
2) double-click loadbang again, now the name is output correctly.

Also, when I press edit, only the id is output from the live.path object to [print 1], but the name, from the live.object object, isn't. When I then press the [get name] msgbox manually, it does output the name.

Note that when I replace the loadbang for a bang button and only press it once manually after loading the device in Live, it all works as expected.

Code: Select all

----------begin_max5_patcher----------
574.3oc0WsriaBCEcM7UXwZZjs4Qftq82nZTjAbS7HvFANSS6n4eu1FxLYh.
BPirRWDi885XNmiuORd00wKSbh15A9J3G.GmWccbLlzFb5W63UQNkWRZMayi
S+kH6YO+NWR5IowbofTjQ36O63mBtrk8Gp1IBuA1atlHyOv3620PykcuVTjx
KHQODC0iX0H3o9u.qvb7pW4WBNe17iULdIUZ.D5CihixqspgAmTYfg22ZXjx
yGR2lk+tl1ACOC5AOo89lqqdvelRREsskrmNH0gSR8.CgQn.8intEwCy9jAY
OdgrG7cQYwnRfkoebngvgg2l8QOrrej7g5FFWBvqMcnWT5FGKgHNbAYDvwyH
t2rFsbVmfLrFtcFrF+nw5R1KzMJGZ1z6KWTJZ5nFbSZRX.JzWMKAkFCSzyfQ
vT0DzEbbA0M5hQflGQolEICqV3s+uk4HAYfr0l2DfMiSF.gSVP.DdkMR7uiM
TdWZ1Sk.CHVaSVitDilLfI8tDvXmXESlmhtGrSdWWUpdULdJUL.sfXrf0l14
2+49FjIjBf7.qcWA8EVNEjS3BNKmTtqlzP4RuUpawcUs1FNUi9.r0qWYfgJT
he8OD1vDs8OqhshiM4mOpyW1fOXSAsUx3DISvuXSphN.z664.qnfxurCUEqn
Vn5d1igQtRmKjzk8uIjhrKj9rBLLjzW+WfaqfoaIS5JhVDSWIAinSH6ho4Dg
ah4rX7T5bwzClNEa4X74TJP+WIroNMmqtj+AHoV7l6eA8do2gA
-----------end_max5_patcher-----------

Live 8.1b7, Max 40387

Please let me know if you can reproduce this,
Mattijs

[hoffman2k]

I can reproduce it, but on further inspection I think you messed up the signal ordering.

This works:

Code: Select all

----------begin_max5_patcher----------
507.3ocuVtsTCBCDF9Z3oHStFYRfBE7N80vwoSJDaiCjzAR0pN9taN.0pCJG
T3hlR1cI7uec2k9lqCbq3DsFBtFbGvw4MWGGiIsAml8NvRxorBRsILHm9rX6
iPOqKI8jzXVB1BJZs9ffKqYuR0dvHeTiY9wRFufJMGD9SihixVqAMVOPjY6Y
7capnYRq7vQpCBrFYVW4G4AvI9Hv8M2g8PjubfZCGtkv2A8.P34PX4Fopj+U
AWJUNozbSvapXjBvshhbn166tt5Eu+FYJDjbqV5.NAiAN39fSrYwPn.TuroK
tD9ybYJHojVWS1QGScQvXS805zEuBq+J0rhi+sbuy7NZAqGXOQ8UNzIPiuLQ
gnxJOjeZxpP7JO0UI3zXTh9JTDJUcA9h7ZVXosLB2zpY2jLZXFrdFn42JkNi
ycTIv7HFQ60D4RZno+BOUrj9+1b8a0WpbX+bWc08Ppv9nXjY9Tb7.nnWymNm
TgWxhLgT.j6Y0axoOwxnfLBWvYYjhMGHUTtDN+ckg15N0q9l1Htvw7NOyAnJ
k3e+OGXjm19WoXs3XUV6iucF.3SIlSqkLNQxD7KBRM0EfOGydVdN03tEakr7
CBFW1nAv8c9S5PkjF.8JIcY0EAM6ZZHRJXYkDd.ZZYkjdxY+RZ8xpogHozEW
R3gPoo1yo17t6Gvbj+bJ
-----------end_max5_patcher-----------

[Mattijs]

I can reproduce it, but on further inspection I think you messed up the signal ordering.

Hi, thanks for your reply.

Yes, this is a good workaround.

I don't believe the signal ordering in the original is wrong. I think there is a deferlow-like behaviour in the load sequence of live.path, which puts the resulting id at the back of the queue, which in turn means that live.object gets banged before the id reaches its right inlet. I can imagine a lot of people are going to run into this problem, so it might be good to address it.

Cheers,
Mattijs

[hoffman2k]

I can reproduce it, but on further inspection I think you messed up the signal ordering.

Hi, thanks for your reply.

Yes, this is a good workaround.

I don't believe the signal ordering in the original is wrong. I think there is a deferlow-like behaviour in the load sequence of live.path, which puts the resulting id at the back of the queue, which in turn means that live.object gets banged before the id reaches its right inlet. I can imagine a lot of people are going to run into this problem, so it might be good to address it.

Cheers,
Mattijs

I recall earlier patches with API examples were using a [delay 0] after the loadbang. I'm not sure if this is still needed and it doesn't work with your patch. But deferlow is used in a variety of the API examples.
Your original patch does make sense. I'm not clear on what the state of this issue is and started patching with the delay in mind.

[monohusche]

As I stated in another bug-thread ("violation of message ordering..."), I ran into probably similar problems when building a monome interface (including osc networking uzi-style value queries).

Andrew (c74) answered back stating that the normal "depth-first" message ordering as valid for all max objects doesn't necessarily work with (external) Live objects. In my case, the networking bit seemed to be the culprit as internal triggering always worked, but nevertheless, I think it would be worthwhile to highlight this aspect.

Otherwise, this might become debug hell...(btw, in debug mode, the behaviour might be different again

@mattjis: are the mattjis from the c74 forum who posted the granulizer before ?

nick

[Mattijs]

Otherwise, this might become debug hell...

exactly my point. This issue cost me one hour so far (bug reporting excluded).

@mattjis: are the mattjis from the c74 forum who posted the granulizer before ?

Yes, that's me, although spelled mattijs (ij is one letter in dutch, comparable to a y in english).

[pukunui]

Bjorn's "workaround" is the correct way to patch this. The original patch will never work.

The reason is that calls to the API are not like normal max messages. It's better to think of it almost as a network connection than a max patch. You can not assume that message order is going to obey standard patching rules.

-A

[Mattijs]

Bjorn's "workaround" is the correct way to patch this. The original patch will never work.

Aha, I see. In that case I believe it would be very convenient to mention this in the help file and reference. Otherwise I think it will confuse a lot of Maxers.

Cheers,
Mattijs