Possible timepoint bug?
I am getting some weird behaviour with [timepoint], which is different to that described by Jean-Francois Charles in this post.
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 running Mac OS 10.5.7, Intel.
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.
Hi Andrew, thanks for the reply.
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.
Ok, I tried a couple of things here:
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?
----------begin_max5_patcher---------- 669.3ocyWtsaaBCFG+ZxSgEWmE4OyoPuaOGSUSjfapq.CBbzRWUe2msAxg0V WWlmSjhLAai8e98cx7xhfvMMGn8gn6P+.ED7xhf.cWpNBFuOHrt3v1phd8zB 4ze0r4ovkCCInGD5tKoUEOi.7z.OzvE7hZpdvu2wJplFguulwqnB8xQN0Yyd wTuvYKRO625EAHqvicOLSwyszAgGtofuKDc+3vsEhsOx369YGcqXXFQw4xmF EmoZSRUsD7J7wGgUp0o7E6aPRnpuWWrP0r7eiJUMEkZw80nB3UpPTqAJEajJ QygJ0z99hcz2fEL9N4OPtWWG+EanRllJYwpVX8GPEhC8UDH7JzFm3oP9h73A oepHboEtLjDPCjXMWhxL4yD43.Ik2DRPqaaPqwWkHJinY.I4QZ9.IlHyrbaj FIo5u08OR0AOPt98esQJ.otL5gUS6bRxjYCGq.yvk7bifIdNfYydgngOCu+Y W3.HGqYX3kA6XqbaCiKyUN6RH9s35Pf.PLelC3F2fOk12FCd9+E6MrRpfaSK 8HbFS4YLxNyomWfgXWkxAR6gJem5hwH.saRp9LBPRzpjOlKtrRPOsBAWkJAC mz+SJD.oImNmPjwzBy5KQDM61UQcQVA6ruwvmmRH1kt8cE791lNgSLw4y20e 4Yk9e6eduYYAMAXnxZFXrdw47TOgvJF+u+Nd8ln5+RH22rua6z6yPv2Rzoso j1KX7BASVZ4zbfKlyirxRpd3IPUyJ04oGk.5920faqhRj6FXgh.uoHxMGi.q jjm0DXilvdUSYVHob+RoHanThe0ThMZh3WMEailR8qlv1noXulaxFL4WJkZQ 9a+5emaAih7phhroFWr2kjqi2HoX0A+g7gCzjs93cWHV4Mut3OfR0Epl -----------end_max5_patcher-----------
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.