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 live.property

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 live.property 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' 'live.observer: 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!

Cheers

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: https://cycling74.com/forums/getpath-of-a-clip-only-with-deferlow

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

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?

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?

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

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

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

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.

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...

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. ;)

jml