all timepoints fire when I change another timepoint's time
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.
- Dec 13 2008 | 6:31 pmAfter 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
- Dec 13 2008 | 7:59 pmCheers for the patch, the original problem is fixed in 5.06-A
