Deferlow issues
Dr Sogo
10月 15 2022 | 12:52 午前
Hey, can someone explain to me how to use deferlow well?
I'm connecting deferlow to the second live.path outlet to send a slot id to live.object and live.observer. The problem is that when I switch between different slot in Live sometimes I receive the id without problems, sometime I receive the message "Setting the Id cannot be triggered by notifications. You will need to defer your response." in the console. I can't understand because sometimes it works and sometimes it doesn't... :/
Roman Thilenius
10月 15 2022 | 10:39 午後
1.) if it says "you must defer something!" that probably means [defer], and not [deferlow].
Dr Sogo
10月 25 2022 | 7:42 午後
Thanks Roman, I tried with [defer] too but the problem is the same. I putted [deferlow] because in the Live API web page say:
Note: changes to a Live Set and its contents are not possible from a notification. The error message in the Max Console is 'Changes cannot betriggered by notifications'. In many cases putting a deferlow between the notification outlet and the actual change helps to resolve the issue.
Iain Duncan
10月 27 2022 | 3:43 午後
If the notification that is causing the problem is already coming from the low priority thread, adding a defer won't necessarily fix it as it won't necessarily do anything - depending on the patch design. The underlying issue is that an API listener-triggered event is triggering an API side effect action *in the same call chain*. The defer only fixes it if moves the side effect call to a subsequent pass. You might want to try a delay of 1 ms or something if you can't separate them.
Dr Sogo
10月 28 2022 | 9:32 午後
Iain Duncan, thanks so much for the explication and suggest!
ninosgr
7月 24 2024 | 9:06 午後
I was looking to a solution to my similar issue and did the following.
I disabled all of "observers" and he problem was gone. I will focus on the "get"request and "plugsync~" . And maybe use a "gate" for the "observers" Not ideal ! But deferlow, delay , pipe, etc did not work for me.
Dr Sogo
7月 24 2024 | 9:27 午後
After some times, I understood why and when use [deferlow]. In general, we have to consider that in Max (or in informatics), nothin can happen at the same time. The machine read our instruction from the right to left.
When we receive the "You will need to defer" error message, it's probably because something is trying to happen at the same time. So if you put a [deferlow], you're delaying the action. Sometimes you need to delay more actions, and in those cases, you need more [deferlow] objects to create a reading hierarchy.
In general, the [live.observer] objects cause more errors, but if you put a [deferlow] before each of the inlets it work!
Hope this helps!
Roman Thilenius
7月 25 2024 | 3:54 午後
[pipe] delays, but puts things back into scheduler if present.
within max runtime, all three methods belong more or less in the "workarounds" category. in live though...