inconsistency with setting a 4bar loop.

May 4, 2012 at 11:38pm

inconsistency with setting a 4bar loop.

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!

– Pasted Max Patch, click to expand. –
#63419
May 5, 2012 at 1:20pm

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

#228684
May 5, 2012 at 8:21pm

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

– Pasted Max Patch, click to expand. –
#228685
May 5, 2012 at 8:33pm

Maybe this instead..

– Pasted Max Patch, click to expand. –
#228686
May 5, 2012 at 9:48pm

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 http://cycling74.com/forums/topic.php?id=3966.

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

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

#228687
May 6, 2012 at 12:00am

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.

#228688
May 6, 2012 at 4:07am

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.
Thanks for the replies!

#228689
May 6, 2012 at 9:37am

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.

#228690

You must be logged in to reply to this topic.