live.object – Changes cannot be triggered by notifications

Feb 5, 2012 at 5:58pm

live.object – Changes cannot be triggered by notifications

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?


– Pasted Max Patch, click to expand. –
Feb 5, 2012 at 6:05pm

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 6, 2012 at 11:58pm

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 7, 2012 at 12:15pm

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.

This thread may be helpful:

sorry – I had no time to look at your patch so can’t give you a specific recommendation at the moment

Feb 7, 2012 at 1:41pm

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 7, 2012 at 2:45pm

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 7, 2012 at 11:39pm

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 8, 2012 at 12:14pm

yup… welcome to the family, we’ve all made that annoying discovery! you’re in good company though :-)


You must be logged in to reply to this topic.