live.object - Changes cannot be triggered by notifications

    Feb 05 2012 | 5:58 pm
    Hi, I'm getting the above error message when changing any parameter of a clip such as looping active, loop start/end.
    I get the problem even in the most basic patch using the abstraction.
    The problem only occurs when changing a parameter while the targeted clip is playing, and it does not happen every time I try to change the parameter.
    I have tried using deferlow as mentioned in another post but twith no success.
    Any ideas?

    • Feb 05 2012 | 6:05 pm
      For some reason it does not happen when using the example from Max Api ClipAudio.amxd
      I can't see what is different between this and my usage apart from the method of obtaining the clip id, and I still get the problem in my patch even if I've disconnected the input to the id inlet of
    • Feb 06 2012 | 11:58 pm
      Ok, what's going on here?
      If I load 'Max Api ClipAudio.amxd' (attached) and modify parameters such as loop start/end, all is fine, no errors.
      If I then unlock the patch, make a copy of one of the abstractions, update the clip selection, and try to modify a parameter, I get the following errors -
      'live.object: Setting the Id cannot be triggered by notifications' ' Setting the Id cannot be triggered by notifications' 'live.object: Changes cannot be triggered by notifications'
      If I then undo all of the above, or even delete the amxd, then re load it, I get the same problem, even without modifying the amxd. I can then only 'fix' it by either rebooting Live, or pointing the amxd towards another audio clip.
      Can anyone shed any light on this? It renders everything I want to acheive with the Live API unachievable, and has really created a block in my learning. I want to resolve it and keep on patching!
    • Feb 07 2012 | 12:15 pm
      Hi Mrboni - its a tricky one, and there's a few threads on this forum about it but they're sometimes hard to find because you can get to this problem in many ways.
      Whatever you do - don't spend too much time trying to figure out a consistency or when it works and when it doesn't - this one just really is inconsistent, if you 'sometimes' get the error, there's something wrong with you patch. Usually, you need to add a deferlow somewhere.
      sorry - I had no time to look at your patch so can't give you a specific recommendation at the moment
    • Feb 07 2012 | 1:41 pm
      Thanks for the response basvlk
      I have tried using a deferlow in this situation, but with no success.
      I also don't understand how I could be getting this issue with a standard included abstraction?
    • Feb 07 2012 | 2:45 pm
      As mentioned in the other thread, when device editing is involved there may appear inconsistent behavior. It seems the communication between editor (Max) and Live doesn't always work as intended.
      So if you just open a Live set containing your device, does it work properly at this point?
    • Feb 07 2012 | 11:39 pm
      Ahh, yes it does seem to work when I'm not editing the device.
      Although I'm pleased it's actually working, it's a bit of a workflow pain to have to save and lock the device every time I want to test it!
      Thanks Broc
    • Feb 08 2012 | 12:14 pm
      yup... welcome to the family, we've all made that annoying discovery! you're in good company though :-)
    • Jun 10 2014 | 12:30 am
      What is the current status of this? Is there a way to actually program in M4L without all of these unnecessary errors? It's my understanding that cycling is fully aware of this issue, but do we have a solution in the works for the future?
      I'm working in a fairly complicated patch in which I need to debug which parts of the Live sys that I am addressing are functioning properly, and all of these errors in the max window (along with various corresponding warnings) are making the whole process difficult. Yes, fine if I know that once I close the "editable amxd" file, but what about proper assurance of functionality in the edit state?
      Thanks, jml
    • Jun 10 2014 | 12:35 am
      I should also mention that I have tried every combination of using defer and deferlow that I have access to. None of them work reliably. I've even put deferlow between both the id input of live objects (and live observers) and also before the output of live.* objects returning values. I get differing behavior (and errors) every time.
    • Jun 10 2014 | 11:17 am
      To check what is really going on when not in edit mode, right click on the device name in Live and show the Max window from there. As Basvlk wrote, the scheduling and some behaviors seem to be very different when in edit mode or not...
    • Jun 10 2014 | 7:09 pm
      As Basvlk wrote, the scheduling and some behaviors seem to be very different when in edit mode or not…
      Which is precisely what I am inquiring about. ;)