Basic Questions about deferlow

    Aug 11 2019 | 10:10 pm
    Hey guys,
    I’ve recently started patching in m4l, and I’ve included a simple parameter mapping app that I’ve recently made.  I have a few questions regarding the deferlow object.
    My first question: In the reference section for live.object and, it says “Note: The Live API runs in the main thread in Live, and all messages to and from the API are automatically deferred.”  If this is the case, why do I have to use the deferlow object in the first place if it should do it automatically?
    My second question: In the patch I included, there is already a deferlow object after the in my patch to eliminate the “setting the id cannot be triggered by notifications…” message.  But I also realized that whenever I’m in the patch editor and I move the dial (which is connected to a live.object) back and forth, I get the message “Changes cannot be triggered by notifications, you will need to defer your response” in the max window, and the error is coming from the same live.object attached to the dial.  But when I save and close the editor, and move the same dial back and forth on my max app in Live, the “changes cannot be triggered…” message never shows up in the max window.  The patch seems to only receive the max error when the editor is open, and putting a deferlow object between the dial and live.object won’t make this message go away either.  Oddly enough, the patch does seem to function perfectly fine from what I can see.  Then I found this page all the way back in 2012:
    It seems that the max editor and Live aren’t communicating how they should.  Does anyone out there know if this has ever been corrected or do I have to live with this?  Should I ignore this error message since the patch seems to be working ok for now, and more importantly is there a way to make this message go away altogether?  It’s very annoying.
    My third question: When using objects like live.object, live.path, and, when exactly do I have to use deferlow in my patches?  All the documentation I try to find on it seems ancient, and if I know when to use deferlow I think it will make patching a lot easier for me.  Thanks in advance for any help.

    • Aug 12 2019 | 11:28 am
      Good questions. Here are some (unofficial) comments.
      1) the reference page of [deferlow] explains its use compared to [defer].
      2) the integration of Max into Live is still not perfect since basically they are running as different applications. For example, inconsistent timing is mentioned somewhere in the documentation. In particular there are 2 different Max windows. The editor sends messages to the normal Max window but when the editor is closed messages are sent to another window (which can be opened with right-click on the device title bar).
      3) as I understand it, you need inserting [deferlow] if a device ID is obtained dynamically and you want to assign it to some object.
    • Aug 13 2019 | 6:04 am
      main thread == defer, not deferlow.
    • Aug 14 2019 | 4:26 pm
      Thanks so much for the insight, makes a lot more sense now!