all timepoints fire when I change another timepoint's time

Dec 13, 2008 at 6:41am

all timepoints fire when I change another timepoint's time

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.

– Pasted Max Patch, click to expand. –
#41330
Dec 13, 2008 at 6:31pm

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

– Pasted Max Patch, click to expand. –
#147091
Dec 13, 2008 at 7:59pm

Cheers for the patch, the original problem is fixed in 5.06

-A

#147092

You must be logged in to reply to this topic.