Adam Jansch

I am getting some weird behaviour with [timepoint], which is different to that described by Jean-Francois Charles in 

The strange behaviour is that a tempo change into the linked [transport] causes hh:mm:ss formatted timepoints to miss their argument time and bang at a time somehow related to the difference between the new tempo and the original (I don't think I can explain the mathematics of this, but it will be clearer in the example below).

What is stranger is when this behaviour occurs... it appears to occur only when Max 5 (5.0.7) is freshly launched. If the patch is closed and reopened (without Max being quit) then the issue goes away.

I have attached a test patcher which demonstrates this issue. Loading the patch into a freshly opened Max the [timer] outputs 15000, when it should be 10000 (as entered in the right-hand timepoint object). After closing and opening the patch [timer] outputs the expected value of 10000.

I am getting some weird behaviour with [timepoint], which is different to that described by Jean-Francois Charles in this post.

possible-timepoint-bug

I think the problem is that you can't set timepoints in absolute time, and you have to recalculate using the translate object after you have changed the tempo value.

I think I understand more now... I suppose the global transport has a tempo value that defaults to 120BPM on opening Max, but retains any change to the tempo value during the time that Max remains open, using the new value when new patchers are opened. If this is the case then it's a fairly inconsistent way of working, although I can it being useful for multi-patcher operations.

In my case it's not helpful at all as I am going to be app-ing this patcher. But I can think of a couple of workarounds at this point, so I'll give those a shot. I'll post back with my results.

1. Reloading the hh:mm:ss setting into a timepoint with a 10ms delayed loadbang - this gets around the issue as it recalculates the timepoint's trigger point with the new tempo.

2. Using a named transport/timepoint system - this did not work.

But surely changing any transport's tempo should automatically recalculate all linked timepoint triggers?

Timepoint doesn't need to recalculate its location in the units it uses. It provides a "translation" if you send it something else, as you are, but the inclusion of this translation is probably a confusing mistake in the implementation of the object. Best to think of it as a translate object connected to a timepoint.

If you want to do some kind of absolute time based triggering, maybe the delay object would be a better option.

Possible timepoint bug?