Forums > MaxMSP

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.

— Pasted Max Patch, click to expand. —
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

— Pasted Max Patch, click to expand. —
Dec 13 2008 | 7:59 pm

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


Viewing 3 posts - 1 through 3 (of 3 total)

Forums > MaxMSP