all timepoints fire when I change another timepoint's time

Adam Murray's icon

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.

Max Patch
Copy patch and select New From Clipboard in Max.

Adam Murray's icon

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

Max Patch
Copy patch and select New From Clipboard in Max.

Andrew Pask's icon

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

-A