inconsistency with setting a 4bar loop.

    May 04 2012 | 11:38 pm
    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!

    • May 05 2012 | 1:20 pm
      For investigating the issue you may post a complete device/patch with instructions for use.
    • May 05 2012 | 8:21 pm
      Ah! I seems like It did not copy this patch correctly onto the clip board. I have reposted with addition to comment markers. Thanks
    • May 05 2012 | 8:33 pm
      Maybe this instead..
    • May 05 2012 | 9:48 pm
      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
      I have placed a deferlow object after + 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.
    • May 06 2012 | 12:00 am
      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.
    • May 06 2012 | 4:07 am
      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!
    • May 06 2012 | 9:37 am
      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.