fhill2000

I have been working on a patch that sets a 4 bar loop with 1 press of a button.

There seems to be a lot of inconsistency when triggering the loop, sometimes it works correctly, sometimes it just sets the loop end with setting loop start and even sometimes it sets clip end + clip in markers instead.

I believe that the events should happen in this order:

I tried adding delay between these steps. It didn't help.

I have been working on a patch that sets a 4 bar loop with 1 press of a button.
There seems to be a lot of inconsistency when triggering the loop, sometimes it works correctly, sometimes it just sets the loop end with setting loop start and even sometimes it sets clip end + clip in markers instead.
I believe that the events should happen in this order:
1. Enable looping
2. Set Loop Start
3. Set Loop End
I tried adding delay between these steps. It didn't help.
Can anyone enlighten me?
Thanks!


inconsistency-with-setting-a-4bar-loop

For investigating the issue you may post a complete device/patch with instructions for use.

Ah! I seems like It did not copy this patch correctly onto the clip board.

I have reposted with addition to comment markers.

Ah! I seems like It did not copy this patch correctly onto the clip board.
I have reposted with addition to comment markers.
Thanks


However, I am still getting the inconsistency when triggering the loop, judging by the error messages displayed in the Max window it seems like there are 2 causes this could be.

1: live.object | Changes cannot be triggered by notifications.

I believe this is just an 'overcautious message' as explained by Broc in this post 

https://cycling74.com/forums/defining-default-folder.

I have placed a deferlow object after live.observer + live.object, this shouldn't be causing the problem?

I don't know what this could be? All message boxes banged to live.object display correctly.

This simplifies my patch a lot!
However, I am still getting the inconsistency when triggering the loop, judging by the error messages displayed in the Max window it seems like there are 2 causes this could be.

1: live.object | Changes cannot be triggered by notifications.
I believe this is just an 'overcautious message' as explained by Broc in this post https://cycling74.com/forums/defining-default-folder. 

2. live.object | Invalid Syntax
I don't know what this could be? All message boxes banged to live.object display correctly.


I've checked the patch and also got the message "Changes cannot be triggered by notifications". As said earlier, the message may be ignored as long as the patch actually works, but should be taken seriously if the patch does *not* work!

What may causing the message here? I suspect it's due to the fact that 'loop_start' and 'loop_end' have different meanings if the clip is looped or not (see LOM). So internally the 'looping' property must be observed to select the corresponding operation. And in this sense, the operations are in fact triggered by a notification.

That's just a theory, but if true means that changing loop properties at runtime is inherently problematic.

What may causing the message here? I suspect it's due to the fact that 'loop_start' and 'loop_end' have different meanings if the clip is looped or not (see LOM). So internally the 'looping' property must be observed to select the corresponding operation. And in this sense, the operations are in fact triggered by a notification. 

That's just a theory, but if true means that changing loop properties at runtime is inherently problematic.


I have just realised that "Changes cannot be triggered by notifications' appears everytime there is inconsistency, I didn't take this seriously as first because I thought it wasn't linked to the problem.

If your theory of it internally observing was true, a deferlow object wouldn't be able to solve it. Am I right in saying this?

I have seen many looping M4L patches out there, there must be a way to achieve this.

I have just realised that "Changes cannot be triggered by notifications' appears everytime there is inconsistency, I didn't take this seriously as first because I thought it wasn't linked to the problem. 

I have seen many looping M4L patches out there, there must be a way to achieve this.
Thanks for the replies!


Right, there would be no way for the user to solve it with deferlow.

Other M4L looping devices are possibly using buffers in Max and not clips.

Right, there would be no way for the user to solve it with deferlow.
Other M4L looping devices are possibly using buffers in Max and not clips.


inconsistency with setting a 4bar loop.