weird loadbang send/receive copy/cut bug

    sbx
    May 27 2011 | 11:08 am
    EDIT: stripped it down, the issue is that a loadbang will be resent every time a clip is copied/cut...any ideas?
    hi all, i hope somebody can shed some light on this one? ive encountered a very weird bug shown in the patch attached: the patch in this case does nothing more than sending a "1" loadbang message to a receive object which is then delayed in 5 ms and connected to a toggle object. the issue is that every time i copy/cut a clip (audio or midi arrangement or session mode) the message will be resent and the toggle will change its status. this does'nt happen if there is no delay between the receive object and the toggle as shown on the right side.
    this phenomena is giving me a serious headache on this other patch i´m working on, cause everytime i copy paste something god knows how many messages are being "re triggered" and its causing dropout´s and such... any help will be highly appriciated!
    i´m on mac os x 10.6.4, live 8.2.2 and max 5.1.8
    • sbx
      May 27 2011 | 12:20 pm
      here´s a better example...
    • Roman Thilenius
      May 27 2011 | 10:46 pm
      this isnt an explanation for what happens or if it is intented or a bug, but as a general tip: i would try to avoid to put loadbangs to high priority by using delay, pipe, or uzi. it can cause a bunch of problems in many situations such as initialisation of graphics, bpatchers, or things releated to presets in plug-ins or ableton.
      in other words, i dont think that a patch which requires a delayed loadbang is the perfect solution. see if you can solve it with a [t b b] or at least use loadbang-delay-defer.
      -110
    • sbx
      May 27 2011 | 11:44 pm
      thanks for the tip, however, i was wrong, it does not relate to the delay object, its a general issue with loadbang..