all timepoints fire when I change another timepoint's time

    Adam Murray
    Dec 13 2008 | 6:41 am
    Check out the following patch. If you click the timepoint bar.beat.unit messages and start the global transport, the timepoints will fire as usual. Ok, but I want the creation of timepoints to be interactive so I can queue things up in a live performance setting.
    Here's the problem: Once a timepoint has fired, if I set any other timepoint in the patch, then all the timepoints that have already fired will fire again! That shouldn't happen right? It's really disruptive to this live transport-synced queuing system I'm trying to make.
    • Adam Murray
      Dec 13 2008 | 6:31 pm
      After sleeping on it, I thought I figured out how to work around this problem: I'll just put a [when] and a [gate] after the timepoint to make sure it only fires when it's supposed to.
      I was surprised to discover that [when] reports the wrong time in this situation! So I am blocked from building the features I want. I don't see any way around these issues until a new version of Max fixes it :(
      This patch shows my attempt at a workaround and demonstrates how [when] can report the wrong time when you are setting timepoints on the fly.
      It seems like when you set a timepoint while the transport is running, the transport instantly goes from tick 0 up to the current tick, firing all timepoints in between. I really need it to not do that...
      BTW I am on Max 5.0.5, OS X 10.5.5
    • Andrew Pask
      Dec 13 2008 | 7:59 pm
      Cheers for the patch, the original problem is fixed in 5.06
      -A