loadbang / this.device: Bug or undocumented Behavior? (When do they trigger?)

[Hokuspokus]

Hello Max Patchers,

Does someone have a clue or hint about this strange behavior?

In my M4L patch I need to block some messages which automatically get sent when loading the patch into a project.

Initially I did that by a loadbang and a gate which should block messages for the first 2000ms after loading the patch into a project. Afterwards it should pass all messages.

However whatever I have tried, it seemed the gate did not block. Until I realized:


1. loadbang

The gate does block 2000ms (until the delayed "1" arrives for opening it) but loadbang triggers when the project is getting loaded, not when the patch (with the loadbang inside) is put into the project.

Is that normal behavior?

It can be seen in my test patch, column 3 (see below the code for it, best to check the patching mode as well):
- loadbang triggers a timer
- When loading the testpatch into a project, the umenu bangs out its output and stops the timer over a bang

To my understanding, the time should be just some ms at worst.
But it is the time between starting the project and loading the patch -> Can be seconds or minutes.

Strangely, when loading a second instance of the patch into the same project, the time between the loadbang and the bang of the umenu is just a few 0.x ms or even 0 (which is what I would have expected to also happen in the first instance)


2. live.thisdevice

The oddity increases in addition when using live.thisdevice (column 2 in the test pach):

It has the same timer issue as above.
However, even if the time is >>2000ms and the 2000ms delayed bang to open the gate should have arrived, the umenu message gets blocked.
2s later then, the gate opens and messages can pass.


Are these intended bahviors? If so, are these documented somewhere? Or did I miss something? I literally lost days for finding these "features"..

Any hint much appreciated! And also, maybe the info helps some others..

Cheers



Ways to reproduce:
1. Start a new project
2. Wait e.g. 10s
3. Load the test patch into the project
4. Check Timer (in ms) of column 2 and 3 -> Time between project startup and loading the patch
5. Check blocked message: not blocked with loadbang, blocked with live.thisdevice (nice and actually what I want from a functionality perspective but still strange and not as expected as timer >2000ms)
6. Load a second patch
7. Check Timer (in ms) -> Time between loading the patch and bang -> 0 or 0.x ms -> as expected
5. Check blocked message: blocked with loadbang (as timer below 2000ms now), blocked with live.thisdevice



<pre><code>
----------begin_max5_patcher----------
2089.3oc6cs0aiZDE98Js+GFwSspNoyEt1GpT6Sakp59PWo9PTjE1Lwlr1fE
LjKcU9u24BX6jELLPBdbVuZUrwgKGNeemy46b.b95G9A.+eVyRefla8qfqTK
K92W281pUguBu3Sk+l0gOLeUXtX6sVEeG8xUwITqI0rlaBYyWFmrXZFcNSb3
.9tdWBm.Hd9hWbD+.AgWBAWW61mQyoIrPVbZxt8ABaq1vfKcl.bku0F0z9Ho
XcbxJJSXtnFVgzBV4Z.ayLZZuDGIbGoyt8Bhm0y+8OsawmlL1NbR.R5v8GfC
2UgVHoq1772tlj+FQbsEdHana+c3Dy1g67V5vmmtdM2Vp0cynOHbPVeNdMMC
LixtmRS.+QXxBv8K4uaUZXDGM.rkTfDZ.gIQxkXYwKVv2lzajKtllmGtf9KE
7CUQ0ur1Co.5mmVjHNt1shf6u1jtQXt.SfRlhmLyHxQsDVOFiZawpW7jTFSh
wPN1LlOUv1Tv.+3e+oOClsJc9WnQ+jUWAHU4FGW7d.DxuO.DLPAPNGdWL9.D
1T.n7koEqh.KnrdiSXxPwIejYBSX+iML8mIbTpq.BhHo6Da3PADGOCEPdS05
Mqfw3VQGE5gv6IzCaW8yWCOEpdSHKbMkQylRSBmsh1jGUsaXOtgJsSqY7x0V
0aU6bruoZ5Rn2yOFGjmyDJL5nmGGHc41ppuDY1GLrKddbqddbW7n2v08vCJA
Vs5VCN14OTBt9YfTplfI.t32.KBYTU19bfLAC3lzLtKDBWmCtD7wz6o2Qyl.
ByA2GyVJUvI0kyVFmGQuKdtPQGaYZzDfbeFtJiFF8XkvNZjRd3ew2FPNKLiw
+jvD.c8F1ifMYo2xgxIfjTVSxHiSXopEUq7kspUzWKsh3N1bADoZLvNXuLpA
ZlQ00WkMUlXEISohCLGoHHygi9BNVEUsTihjwVRXusHeeVaqzCxaA8vwAuO6
PoWs41.Zn2Se2srCb.zzXGviM6nr0QN+nqovZkLzU309ai8aFZZX1YJUBJz0
CaZxoBLF4THrJ7gDfeOnmBYeBInBgsOYTTgbNxN1H5pvGkYZ5p2EpbnDhjY6
D7Z5cQudL12zVqJyhePOKRWGpakVJmQ1g1tyz+HyRqpUpoKEqpx4pAGEMlbz
firaUJ6.AzMz2F5UMjYSioheSE3Ik1Wqy5tvrDd4WwJc+xGmJVuqPW2U+J2w
pRoR1d8djWeR8lzEV0RlR+MAc38Qqb9aRSX4w+m3TRD9zF7Q5nljFOVUtuem
udbcVf+ILodouwL55bEc3eW9nnJ6DwO3sWu88eLb9WZfp7RFUbhpPcyEq6hF
zcmnqC2r4Pxu1ipVeAh7v6nQSCYrrXthS5t2kWOAsj9spfldSyqw2.GEqelK
rz60riqlcRbxcw4wpyUR21DdaKeQ.zMw5paSRSVzwPq5fCd3aCoepasSi3+u
IrqlMf2JeFaOqqiVUI8qiVUoWdZQRTZE0p9M7ou8ie5HW394y.oiIDcTCQnr
7s5Ja9ZU9lz4x2S1lcP7RaUdHFSum9pgx8NYT9nSoY46CQmJcdZep03YYRAC
uuySl1NqbmlaWm9mVcGU5PM3liPvSr138K4ltFcW7G6H9YqB0ygRr6TLeCWB
f.mcsYZNoMz7JEbpU7ScqqX309vDzoR0uR+o5RXYhE+vmZybU4QM7Ithg3SK
QEJupIOvUWjwLw0N5SccbG9zVscNOs0Sooshv9mG2ZOG254Ysd7m05gD+TWY
C0MukqbDfAsT23fY3PDYsmfVlkUDOoRFcypv4zCTSenkmlwCXVjkxQmQscAG
KiAYIpmKLWE1nv2d1BGB5+cOxZG3ZNXKVcu4Mnn1Jr8bTKWZ5wBZ2Sa5lUEK
hSllyM5h7okazU3qOXSB4zN+Px3YuGkYPSzAW9z17l2iwwJT2AaNg5k3lCFO
7739vu6C0IPn4fsN1dCuFck5qy0nu.gL173nWq731p50CJOdIk48ddbjAkFu
D1FVZ7Rb6bZ7KPDyAZQnfgqFu7dx7rZbtZbCJrMHvd3Unqv1yUnu.SL1JzjW
qJz99CuSqRJy68JzXayITuD1FVE5Rb6bE5KvGZTnp2VcTjOips7sDmDuje8X
UOtmmVjMuz9UeADLAzjamlyhSpNMtZ6Hf3fN35dQG00370z3PP0FLJFmmlFm
+HZatZZaAiHnJlZjdVmXjxMtEoYQzLQXlgZ7hAozpwiMTiG2AGObbrcMsbmQ
jQSzz17LE1rtF9A.g0wQaRiSXp6rAm.GoZNeOwK9H31kLAtj3NroOAwiEeBq
KYG6XJoXz2zIlRvf9lN1TRNJtMQ0z1QiobjsGMMJ7fFU6SEcqGqEYDrVsMcX
yavyShiPNpGhZ0W5PHnmLotbQiHWitm5nNW+Z6otpAUD1CIO08a8TejB3g3d
nvuSm57t6E0pUek0RfdaW5z779foFG4PUXeJqOZhNzz3b6brTfsJ1Q802DFs
cIifQ0qdQMiT+8plJRGLqLyOxynR7izcnUHioiK8McmNGmAswxj0p+.CfvNd
aWzDhzzWC3XNMOjtiyaTEPib6Qm5iUkiCQQatwoQy5r6SD2nYchGhB8Dw14B
udp+hWPTR47wpT5lhTtdbliLkJu8v16bWWUnVfblYtX+pRuNFQoWbOlCqgv2
zMO.wTFpl9ltwzyCB1Gu9nk8U2BWsUx+EWu1vMatilkq1G6YPVqCuMU.BAS1
+CiSje39WvXqLp3AnRtC1+u1MVgYyWFynyYEYx6UiGbssd1NKkCyIEw6P5JG
mk759KeH11nth5xaSfO7CO8+.27kpMB
-----------end_max5_patcher-----------
</code></pre>

[Rivanni]

Timer is not the time between project startup and loading the patch (as you wrote here), but the time between loading the device and you clicking the menu (as you wrote in the patch),

The gate is opened two seconds after loading the device.
If you can click that fast, the message from the umenu will be blocked. That's what you want, right?
Messages sent when the gate was closed are not sent when the gate opens. They are just gone.


I don't understand what you mean by "umenu + loadbang -> gate blocks Input for 2000ms . However, as with the live.thisdevice method, bang already triggered when Live started an empty project, not when loading the patch into the project."
How does an empty project affect your device? Can you elaborate?

Loadbangs are triggered before live.thisdevice.
It's best to use live.thisdevice in Max for Live devices.

[Hokuspokus]

Hi Rivanni,

Thank you very much for your support and the time digging into the issue!

Timer is not the time between project startup and loading the patch (as you wrote here), but the time between loading the device and you clicking the menu (as you wrote in the patch)

Partly.

• The umenu should be set to visible or stored (visible in this case). In this mode, unfortunatelly, it will output the last selected (and stored) menu item automatically at project startup (this output is what I want to block).

• The other part yes, I agree, when loading a new instance of the device, it should be the time between loading the device and when the umenu (automatically) outputs its item (in this case "Why").
  But it is not. At least on my machine. That's the bug(?) I see.

How does an empty project affect your device? Can you elaborate?

1. Open a new Live project
2. Wait ~20s (what I will use in the following)
3. Move the test device from your library (or wherever you've stored it) into a Midi track
4. The middle and right message box at the bottom (showing the time between start and stop of the timer object) will show about
   2xxxx.xxxxxx (ms) ->~20s -> the time time between starting the project and loading the device, not the time between loading the device and umenu output as we would expect.
   (You can double check by opening a new project again and waiting e.g. 30s. The middle and right message box of the timer also will show something like 30000ms then)
   -> Bug?
5. Also, as we have ~20s >> 2s, the "Why" message gets not blocked anymore and appears in the middle message box (in the right example using loadbang)
6. Load a second instance of the device in an additional Midi track
7. The middle and right message box at the bottom will show something like 1xx.xxxxxx -> ~0.1s -> the time time between loading the device and when the umenu did output "Why"
   -> as we expect
   -> but a time like this - at least I - would also expect from the first instance
   -> Now, also in the right column "Why" gets blocked and does not appear in the middle message box (as ~0.1s < 2s) (the functionality I want)

But then comes the even more weird thing in addition.

• In the first device, the middle column (using live.thisdevice) also shows ~20s like the right part (using loadbang).
• It should be the time between when live.thisdevice starts the timer with a bang and umenu stops it (by outputting "Why" which triggers a bang).
• The stop bang is ~20s later (as in the right one which uses loadbang). Hence the delay of 2s already should have passed and the gate should let "Why" go through to the message box.
• However it is blocked.
• For me, that does not make sense at all. Bug?
• Either the timer should be <2s and the middle message box empty or the timer is >2s and the middle box shows "Why"
• For me it looks like the timer gets an earlier (start) bang (when the project loads) than the delay (gets the bang when the device loads). At least that's what the message objects show in the end.

It's best to use live.thisdevice in Max for Live devices.

Yes, I see this now, too. From a functional point of view it gives me the result I want ("Why" gets blocked for 2s when I load the device into a project).

However, when loading the first instance of the device, why does live.thisdevice trigger the start of the timer at project startup (see the ~20s) and not when loading the device even though the 2s delay gets triggered at device loading time (both, timer and delay getting the same bang)?

[chapelier fou]

Hello !

firstly, it's good advice to use live.thisdevice as it outputs a bang when the Max API is ready. I generally use a single instance and link it to something like [s ---init] although you need to be aware that the timing between different receive objects will not be (?) predictable. If needed, I would use [t b b b] connected to [s ---init1], [s ---init2], [s ---init 3] and so on.

secondly, it rings a bell that [live.thisdevice] would not work properly if you open Live by opening the .als file, or if the device is part of your default set. I need to check. What if you first open live (empty set) and then open your set ?

[Hokuspokus]

Hello chapelier fou,

thanks for your reply and tip!

What if you first open live (empty set) and then open your set ?

Having a project with two instances of the test device in two Midi tracks:

1. Opening the project together with starting up Live

• Middle (live.thisdevice) and right (loadbang) timers (measure time between these objects start them and umenus output the message "Why" which stops them) show ~3000ms in both instances -> Bug?
• loadbang test (right column) does not block umenu output anymore as 3000ms > 2000ms
• live.thisdevice test (middle column) does block umenu output even though 3000ms > 2000ms -> Bug?
• Adding a third test device in the project when its open-> ~100ms

2. Opening the project when Live already is running

• Middle (live.thisdevice) and right (loadbang) timer show ~1500ms in both instances -> still buggy just faster as Live already is running
• loadbang test (right column) does block umenu output as 1500ms < 2000ms
• live.thisdevice (middle column) also does block umenu output
• Adding a third test device in the project when its open -> ~100ms

secondly, it rings a bell that [live.thisdevice] would not work properly if you open Live by opening the .als file

Would be nice if such quirks are e.g. documented in the Max reference documentation.. As else, people literally can loose days on buggy or undocumented behavior. (With respect to those two above phenomenons, shame on me if they are written down somewhere and I have not found them)

Unfortunately I cannot upload pictures here..
BTW, Windows 10, Live 12.4, M4L 9.1.4

[chapelier fou]

I would narrow down your tests to get what the issue really is. I'll do some tests if I can, no promises.

[Hokuspokus]

Cool thanks!