It seems there is some strange behavior with timepoint when you try to:
1. Use a timepoint object to "loop" a transport by rewinding the transport to 0 everytime you hit a certain bar.beat.unit.
2. Use a separate timepoint object to try to detect that same bar.beat.unit that the transport is being rewinded on.
For example, you have a timepoint object that is banging at 2.1.0, and you use that bang to reset the transport to 1.1.0. Then, elsewhere in the patch you have another timepoint object that is banging at 2.1.0.
Expected behavior: the "remote" timepoint object should bang each time the transport reaches 2.1.0.
Actual behavior: the "remote" timepoint object actually only bangs every other time the transport reaches 2.1.0, resulting in only half the number of bangs compared to the timepoint object that is rewinding the transport.
See attached max5 patch to clarify.
Can anyone confirm that this is a bug?
I’m using Max 5.0.5, Mac OS X 10.4.11
how does one go about submitting official bug reports nowadays?
I think your bug report was quite good. The c74 team was away this
Monday/Tuesday, but if they don’t answer tomorrow, I suggest you send again
your e-mail to support @ cycling74.com
On 7 oct. 08, at 01:57, Scott wrote:
> It seems there is some strange behavior with timepoint when you try
> 1. Use a timepoint object to "loop" a transport by rewinding the
> transport to 0 everytime you hit a certain bar.beat.unit.
> 2. Use a separate timepoint object to try to detect that same
> bar.beat.unit that the transport is being rewinded on.
> For example, you have a timepoint object that is banging at 2.1.0,
> and you use that bang to reset the transport to 1.1.0. Then,
> elsewhere in the patch you have another timepoint object that is
> banging at 2.1.0.
> Expected behavior: the "remote" timepoint object should bang each
> time the transport reaches 2.1.0.
> Actual behavior: the "remote" timepoint object actually only bangs
> every other time the transport reaches 2.1.0, resulting in only half
> the number of bangs compared to the timepoint object that is
> rewinding the transport.
> See attached max5 patch to clarify.
> Can anyone confirm that this is a bug?
This doesn’t sound like a bug to me, it all depends on the order of
which the timepoints will trigger. When you have multiple timepoints
with the same time location, the order of firing is unknown, and you
shouldn’t rely on it. I would suggest you use delay in that situation.
Hope that makes sense.
----------begin_max5_patcher---------- 567.3oc4WsriaBCEcM7UXw5Tjswl.cW+NpFUwCOYbEXGAF0Lcz7uWrA5zTAA m.gFotH13qectm64Z67lqiWp7Dq1C7YvWANNu453XLoM3z21wqL4TVQRsYXd B1Ojoe2aWWWJ1IkwbNqH4U.bvtnoT1nJXJyjP8V6Lod8HqaG8RSDG7.O02MO 2rTsK+mvCKzyRgRjTZlf2Wp3IEC8bLQk8BWb3aUrLU25EDg7g6.HbjthDqKw Pe3u2gVXwECnB+GaQM+mls.g8gZqu65pK1YKozTlxpF24wS47bgxa2E3.5Mw ATRnwsCg5JJ7xb.ZE4fwEFYxFgZJtgLC2L7S2bLJJbQTDlpq1GbYJh9fKSH2 DGPnj+ejInEQQatLIsQojh05nTBc9TATLZv6tnLX8h2JdI6nrMfAP9sL6p4r K5DAD0Dpih2rrgUNTSlWNihg2qPsRd3PA6JcloxYI3K3K3trQDxTQPCk2eYK .5ekN3yExjIbQ3hdkSTWHb++5ituSoxAAKgchi23L4oHmpDQ8QYkZbZIdla1 5q5zPi9wXiZb971dScepFtSmglStYwipMSzqfK96+3gY201OmlqkMUYC7R+0 4fO19bVshKRT71yQ+XLjyFyK77bloaXukRdtQy1CAvSiFxsEQDhEPBsoPJzB DQ2VRhZAjB2THgsQIQd7fDbSgj9j3YwDda0R1HuIar9FZAlzmBCPaGlv1hI3 iEltVINNB6SaY18l6mBZej6PqyPaai2c+EPjbu0D -----------end_max5_patcher-----------
I disagree. I believe it is a bug. There is an object that doesn’t work predictably in all cases. It doesn’t behave the way you would expect it to from looking at the documentation on it.
If it’s not a bug, then it’s a feature that is working correctly. Why would we need such a feature?
And it’s not that I’m trying to rely on the order of the firing of multiple timepoint objects with the same time location. I don’t really care what order they fire in, I just want them all to actually fire every time. If a timepoint object is supposed to trigger at time 1.3.0, then it should trigger no matter what.
I believe what you’re implying is that in some cases, the timepoint object that is rewinding the transport fires first, and thus rewinds the transport before the other timepoint object can trigger. In other cases, the "remote" timepoint object fires first, then the local one fires and rewinds the transport, and all is well. I believe that is a bug. If the transport reaches 1.3.0, then all [timepoint 1.3.0] objects should fire, regardless of whether or not one of them triggers a sequence of events that changes the transport time.
Quote: Emmanuel Jourdan wrote on Tue, 07 October 2008 22:42
> This doesn’t sound like a bug to me, it all depends on the order of
> which the timepoints will trigger. When you have multiple timepoints
> with the same time location, the order of firing is unknown, and you
> shouldn’t rely on it. I would suggest you use delay in that situation.
> Hope that makes sense.
Hmmm… this does make sense, but…
It is perfectly acceptable that there is no guaranteed order that timepoints will fire. However, if the transport hits a certain time, all timepoints should fire no matter what else happens during that scheduler cycle. If a transport time is reached, but only some timepoints fire, that is very counterintuitive. It’s a "leaky encapsulation" – the transport system is no longer a black box that just works as expected. I’d go as far as to call it a bug.
Perhaps it’s not worth all the special-casing (and maybe a performance hit) to fix this problem. But this kind of situation is going to remain one of those gotchas that will cause confusion for a lot of people. I can see a lot of people wanting to build a transport loop control, and then independently from that use transports to schedule other various events. The fact that this system becomes non-deterministic without extra, non-obvious workarounds is very bad for the user.
So if this behavior is going to remain, I suggest at least add something about this kind of scenario to the help files. But I think it’s safe to say that those of us who use transport heavily would very much like to see this behavior corrected.
Quote: Adam Murray wrote on Wed, 08 October 2008 07:56
> I can see a lot of people wanting to build a transport loop control, and then independently from that use transports to schedule other various events.
Whoops, I meant: "build a transport loop control [with timepoints], and then independently from that use [timepoints] to schedule other various events."
Long story short, timepoints should always fire when that time occurs.
This is one of those frustrating situations in which a user is not doing things that we expected. I don’t think it is a bug, but I see how it can be viewed that way.
When the transport is changed as a result of a bang from a timepoint, the value of the current time is changed immediately.
This is what you want, because timing accuracy for a loop depends on the real-time equivalence between the old time and the new time. We could, when seeking the transport, wait until any other events at this same exact time were executed, whether temporary (from metro 4n objects) or permanent (from timepoints). That is not how the algorithm of the scheduler works now, and I have no plans to rewrite it at the current time. I might might consider changing it at some point in the future, as a feature request. I would need to determine whether it would introduce certain other problems.
Imagine a list of things to do at time X:
A. go shopping
B. pick up the kids from school
C. change time to Y
You could argue that we should use mind-reading tricks to sort these events so that C always happens last. But that is not how the system works. When C happens before B or A, the time is no longer X, and therefore, A and B are no longer applicable. Sorry kids, maybe you can walk home.
Perhaps I am just trying to do something the wrong way then. Here’s how I ran into this problem in the first place:
I have a patch that loops a transport, let’s say a 16 bar loop. While the loop is running, the user can choose to time certain events based on the transport position. For instance, they can mute that particular channel at the "next beat" or at the "next bar" or at the "next loop".
So, if the user chooses to mute that channel at the next bar, then I get the current transport position, add a bar to it (and cut off the units to 0), and send it to a timepoint object to trigger at the next bar. No problems.
However, how about if they want to mute a channel at the "next loop"? In other words, when the transport gets set back to 1.1.0. Or, what happens if the transport is at bar 15 in a 16-bar loop, and the user chooses to mute that channel at the next bar? Then I’m going to end up with a timepoint object that is waiting for the loop point to happen, and maybe it’ll trigger and maybe it won’t.
Is there a better way to accomplish this that doesn’t use timepoint objects, or uses them in a different way?
Also, is there a particular reason that in my example patch, the timepoint object that is NOT rewinding the transport gets triggered exactly half as many times as the other timepoint object?
If it’s not too much trouble, let’s have a look at your patch
You can send it to me privately if you would prefer.
David Zicarelli schrieb:
> When C happens before B or A, the time is no longer X, and therefore,
> A and B are no longer applicable.
Out of a programmers point of view everything is sequential. But even
programmers got to the point and found solutions which is the human way
of thinking, We want that C, B and A happen at the same time. If all
timepoints are just a reference to a single event, then they could all
still recognize that it happened, or in other words, it had been reached…
> Sorry kids, maybe you can walk home.
Sorry Master, musicians tend to insist of not being programmers, as that
way of thinking doesn’t make musical sense. If we would just walk home,
the problem still remains…
I know programmers can switch to parallel thinking… ;-)
Emmanuels proposition to deferlow the reset unfortunately breaks the
tightness as you correctly pointed out. As all transports are actually
one, why can’t all timepoints who look for the same time be one?
The obvious workaround would be to use only a single timepoint and send
all infos to the places you need from that one like in the patch below…
But the same method could be put into the timepoint object, I expected
the timpoint to be nothing more than a receive object with a match for a
transport point. It would tell transport which points to send into the
world and all would receive the message and compare it to their stored
match -> bang…
----------begin_max5_patcher---------- 650.3oc0WsrbaBCEcM9qPCqc8nG7xcW+IxlNY5HaTbTGPxCHl31L4euf.rcb ff.iUbWXv5wHcNm64dk30ENtajGX4tfuC9Ivw40ENN5tp5voosiaJ8v1DZtd ZtB1KxM+1cY8PJ1Akt6TpZ6y.zJxJX6XOIEJAMkoG+AVVLUPaGSTjxEILkdM QMctuZM3hc+JisUUiIuffUvk.LhT8BAg5VkOAOd1tjy+qdWPnxgOtAxB0k6P cWp+rmUu7ttGWGdrFmkb6aHraUeusXQ0ikWmvjAT7T1dIWnFsv.GTXPQg1TX PSQXRY44zcrOnLSyrf+DMA5oECre0KeXs.cikD3L5UxuBuBZXcwGcUdE3GYe zjHeQ5FVVmD7GYbZxXomeTTEgHvfSg89YGtG1g6KrqCF.2MTwtNc.9ynAXqr PnFs13On1fC0g9PxzzFuAzl1eUM6RhBtGrIMULIvvuDah28rMo8X1P7WoMYR mtroPojhIVy.SBao5ED1vyD5ObOmkENdpvmbAqqozIFpKODsdZw8InNA1KT2 5sucg5IkZqj61kvFKYv04ln56C6gZeNVxzWJn2bd0WE.tZ97pjn5quDUGACm Yu5SIRZOZB7+gT4F4Y8Z6lISHyo3jQE46kYpQJK3ASXv09EzTsMqG3nslW0l nN+SWypaE8cof5Y3lvEW9U5ZtV0+6k4bYQ11Vv07wrKAmXaLKWwETEurP5oI UVB67I8LONlIN+N+o7XsqsADfG6LnaLlPFfoK.9MGSPCvTjUgTYtkAxD79CS d1ESd3a.lvQ3U9kULB0ULHqgGaYCzRrq42CZJlP1CSAlDU8sqN4a.lBrJjLQ krrH4YRYK6Vb2DqzUfnxFus3e7qmYID -----------end_max5_patcher-----------
If you want to do something at the "next point in time" independent of transport position, you may want to think about using a delay object. delay, pipe, and metro wrap their intervals around loops. This is generally more flexible than using dynamically set timepoints (which, as has been noted, broke somewhat in 5.0.5 and will be fixed in the next update).
You’ll probably also want to mess with quantizing the delay.
----------begin_max5_patcher---------- 638.3ocyW00jaBBE8YyuBFeNMCfQWsO096nyNcHIrYoiBo50oocm8+d0Kwcy WZXUqMuf5EPNbtGN.uLyyekYurvm7Yx2HdduLyyCCUGv6v2d9Yh8qSEEXy70 xeYV8C+41p.4d.CCpL4NiRCjjErEzl50kYJcpDv9xNDTsA6R0u4S7vlV9jQC ZQlDq5q4JQZSM6Dv5mU5seOWtFrPkmvWPmSBBpKiSpK4zETxiuOrlR37w0FB 98No8u3uRn25+VmpQPg5OXkrp+eczWmMqtXtijyZSVlTCWvN5pWHqD4NSKK6 GsPiqoB1xP7QH8FDCskYdyHjKKplMBPYzsNJzCEjGGc9RJ.mIrfdRXQ3Tg8v vHrdL0WUBfQ677i1wrfEyrIjkMveLVNzR1OHzJt3QCN62hUhQKQjbMpgeI0v h6oEBZdvCwTusrCRi2IoM+VdI2XE0IXYPb5GSVwR5jgP8T.kMAxpSGr6AY0C 8RVEaWCFxmBU0+d8QjC1NrnQQeLdY5LIjaHLM4K+rTngJBC+PTBlBPjCDlyh fdtObB5Qxa3j36lCnjIKJDakWPYTmYD9PNvVD5yEvWDVoah+37wnxEfY61To yKE5dGXLgGNPmxpiOOpKDfbgtXmIGbM61usRYVSuDqc.+VldIcM8m+1imRMh Vd4Zs5+nKYXW6GXcBRtO8HWdrG4x94QFLj8I4roxgDaiepRe90cQvUG+TRrv TlutYTZ1Kf7N91HK.kFOFywMJ9jF8rZyFo93aNjo1fWS9.HZIk5JlBbAROLo Pp9F82FS7oESTWScrICSmoTZASISJOclT45XJbZgTjqR7IL0wc.SSrZh5Hj5 alq5iWm8WX5tspH -----------end_max5_patcher-----------
the only problem with delay is that it won’t work with a fluctuating tempo. The patch will have an option to gradually change the tempo over time as well..
I’ll take a look at the examples everyone posted and see if anything works.
I think I can get it done with one of Andrew’s suggestions; it’s just not the first way I thought to do it, I guess. I still think it would be a lot cleaner if timepoint objects behaved the way I think they should, but I understand that there could be ramifications to modifying the scheduler code in this way.
The two ways I’m going to try to work around this problem are:
1. Use metro objects synced to the transport, and have them fire into gates or onebangs that open selectively when I need to know when the next beat/bar/loop happens. In my patch, this will result in a whole lot of metros firing bangs into closed gates. Not sure how that will affect performance yet.
2. Keep using timepoint objects, but instead of setting them to look for the actual loop point (i.e. 16.1.0), I’ll set them to look for one tick before the actual loop point, (15.4.479). While this is hacky, I’m really not concerned about one tick which, for most tempos, is 1 or 2 milliseconds or less. The only tricky part will be making it work when I’m in a time signature that’s not based on quarter notes, like 6/8 or something, in which case I’d have to trigger for 15.5.239 …. yikes
Also, Andrew, your solution using metro and onebang doesn’t allow for time signatures with an 8 or 16 in the denominator, like 6/8 or 5/16.
Another possibility for you is to roll your own bar counting mechanism.
Set your main transport with a bar length of a few zillion and create all the looping tempo changing timesig changing stuff yourself.
----------begin_max5_patcher---------- 1336.3oc2Zt0iiZCEG+4jOEVn1mZ1HeGnRiT6mipUqHIdyxJtjELsS6p86dA aXxkMXbRHNL4ExDfg7+7ymywGeLee9LuU4uJJ8.+N3u.yl884yloNUyIl098 YdoQutNIpTcadYh+Ie0W8VnujT7pTc5BP8E9ToXsLNOq6p6hjq+Rb11OUTed 8OBIjrDt.f8aNFvT+MbID7w1+k3MpGW8OwGXjtmymyyjYQoB0k9yh3njtqjU kFmkHjJsA2ex7JY2YQG7PJi+O0CAgW1cy56T9u6DZA54A9XyU9w74MGVbaXo zRrvzXg5Gn3huQtfuPtfNKWf8vkqv3SEkkQaE+j0CMXwbNWYwDksRvKYK.nf drXzEZw3wxSnS+EhRQlLpYT7HaHPaCgMe.aObU9O8gPjImFFT+yyr.gvGEBG yfogCjnPk+DBQa9fEXJPhxlZARqpjRilWaTCI.2Nj2d7rlG8BLBTeifqhx1N bf.Sm9J71CDFDAsd8j.hEHfLhHX7bj2FIEVLHSTduDpQe3oZpQcdclN2zM4Q bcPryMQiuAf3SPxwWdAfF1mBy0TwXgWjvGBNhyjiMQfC6ff4XKHRvSAQJrXB TNTWfNRk7gwMhE+2+UnKiSE6xqIM.sDUaslPS.RQiPEZBMiF9nTawkhlQepp ivCzHdXbcLTnuE3g8bfmj7nMpGZ+XIHbONzYe6EJzmCn7aFmIB4qRvvfGrvu dIB4oHu6GrAHTF1BffeJ.hDvpWopojIsKpEqaTD0XCQHvQItAeEPYwsvlpzU hBKhTZKk1XtCb3ijAidJjeEPsHhIPgDDEYJjA6+jDxP.HnoPFhu8gLX96xPl AaN.EoX.J7s06YfArGayAFzXH55MsyXllc5nTj.fFm8iDpl1Coa1A0XUiXzn 30RtlBjVr+SuQsCuRQ5tbvuXhQ3118AU9CbsWQOM5E+DzKCIXEH1DOz8cG6S GthITvCISWmuxUmpacdZpnIc4Ir4aU0OxpcIBPyRy.6pRJEfWFpZJclD89sg LWIAx+t1UbysMjQa6pavM21v9.nrH9moGzB5wI1PO9TaOEJh1DmusHuZ2vaK qtIgn2567YsvQYaE12.435DfcWnyr6L4tnt+NJo5naXSbYzpDwF8SqwKYT8Q ZaSFXkwRMzwTZvgM5TPdjgTnVG1v6VHUGthFFWbav0jaCt6YdpTgrHGPy.+w 2phxj0+FpuDUIyKkQERyK6mEdP45X8b68hDF+9Msd8xmBYn.+wupPY91sIl1 klv1cmQ6hR5NdVD.Gi7N28UqSQ96SKz2vYv6yEq2aIr0ykVFuEf3j.pwUtqa FJBqF1CYlJjk+NpN1q4EfAy0M.kvG9s2f9DTSeQTV4t7B4voDIcdIFagw3rw 2gWeGLp+3yI4Q87Gm6tNFnJixKIN6zW.OEYZN+wTtLupXcmN51iIvd1rQTJi yTS+evM07BB.PucSeIdyFQ1gSOlFuQsAOshnmwbq0DyFMAcplZdQBGTSMk0d vMc20DxBM07l94RMAmdZhRsQSH2pIa7mNAl2aMgrgSTla4jM93T2F2QswG+j A36dNy.ayY5PM4aglNQ3SCME5VMEZ6bvNTS1jKf6VIYSJSraG5vV4N43TAXa 3juS0jMYmHtsp.BzVLgbqlPCUk4Elwj5q2bC8d9f88e6a2pyuM0oSb6bNX9z aTUooQeTEcuFUsJMqaS8iQVPPLy8ZZPNQldUvicakDXaxy5VIoh0FzcB5dMM XQftURL9zanaB5MYgyjaWjyzaXiZoht1Ikq+xOl++1nG1PA -----------end_max5_patcher-----------
>Also, Andrew, your solution using metro and onebang doesn’t allow for time signatures with an 8 or 16 in the denominator, like 6/8 or 5/16.
Now it does. I think this solves your tempo changing problem as well.
----------begin_max5_patcher---------- 625.3oc4W00aaBCE8YpT+Of7yYQ1lvW8oseGSUSlDWpm.6L3hV1p1+8YrKIz kPiSRIrp9BFt1W6y8368XyS2diGJSsgWi7uy+q9ddOos3Yr0ZwqyfGpjsYYA q1LPjj+SU12QydtOfuAL1AQIesRHA+z4j43sCP1TpZfBNXbmzY9AkDjrRtw2 uTIXEa8vNb3Wq4VjgxXxbj+8c8KVYbRihOQCQ8mvZwuM9Pnywc1WyfkOJj4e qhuDrSX.NV2u+hj1mIosOo343cqfFyB4VHaL9mauosU2LyYpZoprjKg84Jo9 E+LV0.jD1ARpOIrXGITkmYiQbaTs6Aoe3cBTEkFXbOxNKg3ohr3L3MhsBFS1 hXbOfN1rUVC.J4wJxNkJocUrGHvHoQ1HZawxHEWCotnjbC1Ob.SOaUkYuFmP RNK0EhkdhL4BgwGgqn++jCPRQNDWIIenxAhOmbfTachU07cUJPjKx.AjIJEn jCUpV4Y8Z94ezvjfd+n6aVCnpAVE3StN29fr3RzGBBsMKFsriRdcMKmuOM9l d6rA3F5EbyrXiDi9TzPcxVxHvLfJOufex0M5a2NPz9pmdRwlc7nnIppApXx5 0ppgtAU54rs2xEy117PghMvKGZTGlEOqiaIVsVB1JMQeGI1FhN9QHIgSpT6B YOc11Ot5hrAWv4ucZqImXNgcXnBgbu+N1rXsc7ObZspoZYWzzc3feuEbEuFD RFHzoP8FUxKG0ihUq3xW7aMkhUl+q9Yj3e+va0tCNrKfahvF0UrQt9XKxoM0 3oAbwt.tvoYSMwIhKcR.GE6bo50eWkF5D3nSByE3b4vkgsVC5l+BB+DkLC -----------end_max5_patcher-----------