So, I’m still at a loss to figure out why the transport and timepoint system don’t have a mode for just working in straight elapsed time. Yes, I know about [translate], but is there some reason we can’t just have a mode where the transport reports elapsed time and we set the timepoints in elapsed time? Unless I’m missing something here? It makes no sense to me that we have a system for handling time that doesn’t handle time natively, but forces us to translate between bars/beats at a given tempo and time signature on the one hand and just straight time on the other. I’d be happy to be shown a way to just work in time, not bars & beats, with the transport & timepoint objects.
Can you say what it is, specifically, that you want to do that you currently can’t do? Maybe an example showing what you dislike?
I think the whole point of the transport system (when it was introduced a few years back) was to provide a bars.beats.ticks system for those who wanted to keep track/report time in a traditional musically notated type of way, as opposed to milliseconds. It provides a traditional musical way to report/work with time in beats and measures instead of milliseconds, which objects like [metro], [timer] and [clocker] use.
Is there a specific reason you wish to use transport instead of those other objects? [metro] and [counter] for example are a good combination.
But, of course, it all depends on what you’re doing with it.
FWIW, here is a method I have been using for a time-based transport. I haven’t done it yet but I’m sure the [clocker] object can be linked to the master transport so you can have parallel timing in bars:beats and in h:m:s:ms.
----------begin_max5_patcher---------- 2111.3oc4as0biZCE9YmeELLcmoWx5hDWLr8k1G6L8gNs8sr6jACxXsAPdPx Ia5N6+8Jg.LXyEYGLgLMyt1IRBoO8oyEcjN70aVnul7EDUW6CZ2osXwWuYwh 7hDErn3uWnm3+kfXeZdyzSQOQV+Y8akUwPegkWbLwOLAQoZ.C9OkUuEGFhRE M.TTxFRJih+WTdYvkFEEmtOAmFiXz5skWHYO63Rwg4CHGDu2obb14yB1hSit OCEvjyFSG6k12xgCeLz77DeB4+t1mpAjT+jbfn+aYX+3xNSNlrm2gj8jtt1m D07satQ7wsJRTAjjDTJ6Dl5evInXbJR6OPoQrsZeeB8Gzaic.Urylrn0hhLp JYWFhx6beFljVeRa4rDxm0l4y5xOplyJvxFmxxV8wxvUhAQNd.fY9Wd8SyW. WFieDsjCTQqJ53G8yp52VpVgoJ7zop4vBTV4hR1N4yT6ZyzSEatUSeCWuf+7 eppay3XlgxtGk5uNFUGbT+GQg26yXY306YnC+FsfXJXFwTOdOhror3xxq28T FZW9y4HTGu8zFrOEynrmkP.1RCR3K.UcPkfWilTNWaqN5VRFqmEnFMNljF0Z akMMWXo7qQRK7uPr8YoikdmsStjuo8pQTuC1ivHjORGTzstV5ccwd+8N+.zZ +rQytkKTxeliH+A5g+r8NX1x18ZZ0hQhh3ZYcY0pY09ALdgqiHoAjXRlDq.I cXa.7b.ErC37XmV7cZZOH8.LjqJqJ+rGacSuINDeJVL5jMaDFaIoUvnUSYfd shAUyJViErArhUz1WtUrj8wLLMFGhpT4HY3REo5x+qIYgBrf1vpWb.WfNzm4 We0XczwBYG9nt1GEw3BXEb3cR4On0JGikV.HvvqeAQ1VbvCoHZiBKPYFNZaC XNrCZuAkZgltxuxmHldC4hteQWiQzp4eF6+7Yaw7xr8Y1qyCK4t0jDj8Ux5W GAJPQwZ.S8yHb.npBGPmdmz4RGqbN3v7RiGXseZTgjy3wKOfd9bHk10XrNkT 7FlSJ1RqmX6sWJmfEx6s80XxQ6z1lPuOfrOkgxzuJQT5Nr8EWKAQ4Y7BCor9 3fxN1A3FbL5QTFsv7dAT46PX2tZE2z2Xh+mklycp7Nw4.YQfphxPOhKediRW Skc+gI6JocAfTBQFYmkQMyDBGHwjfGPg0iAPmrCkhSquOuFUGh13yclce6qZ MqeCeSlc9vsRzKzixvgjTAHZ7jhhKGt6xiaqYzaEsH0eWKOLkOO1S4a2UPbq aFxjNiPhaVU0ZEWF2OEm3yPLrDrvpXwzwI6xx0OpMPR2NaoAYj33FckrlGao lP9xY.5IbHaaCGGhZ3MGuqbIPuhiBwQHJqYYL+HZyRZbxP0kypq71n7dcC1T SNgVu3NDFZ0gXmJ2c6Xrq.C5RO2qX2uFGhQntdde9HqsQuR6cWB00v92Q9Oy Ea1n8Qw9xzdG8i5JxjJxYf14L3.blbOEPmbMKOfpbVsZ65X2t9T56xOzxKgF gmKM5M.MZZsRRc47n8nviG7Be8oRtN+ZwYatk+GI7+S0VpkP090c9gg7YpFT yn5+lZ+JO7unHt6r7RrtjUfUctB.6P42PMIY49hMsfihn7sSn37Oq4LMBy.f ZToTX1Dd79Km6BySGQ5pDQBbLdaRjuaxHRyAHRfIXoC+mUvCxktu0LxNYzIz dH4RSukl7errdCSm+nXykFfogQcTSSu3b88FCtr7NnFQ1j2khSecT23YG9qg JZaTtacYTqiCicawI8znm57LBGIlMmoz6h8LNW4MGakXOKYPN1ke1XJ28gWT bzxxv7xCdbDYB4vpOZQ84nlpmokcObwPS1Cmmf3J96H747wVTe6r.krOKnjq K2xpVSbvismgSqNdk6pBR6n1cHALpyJgXpP1MTcg2yFx.EgbKysWMLadNXFN OvrqpXFLe3Ykwr4rAyPEgrvHybAx1mi3r07.yNphY24COqJlaYA4UCyppBBc d6gYuYCjcTUEDNeDm8NGqFNi.jKBLo7NnJRRD9Pv2XVOYHxK8hhF9hnNiaOo UPzyf20fFESV6GWbkfUOaKWRykmJIhvdQg3SyNACiOv+GeSvqpNcgF3Le6wc kkBMxkjFIe5YmqRk2gMyecBID0QBNXCGN6t.t4GTVQhfX16M0p86L+XbfdeY JRwsZ2LoQxH6SCkR2lGRys1hRrbRDkR3PkOXOTmDdhjE9Tl+t5MUr1bFIBVF xOjjF+b8tsJLDv3cM7Ls0WkKe2quzuEBjobqiLMErdwIvwXlXBEGXvKMmVZi SfCyIPCCAmXCeIbR8SI5byNMDk5GgN0hxxqBk3pPJs.LqcmCb6.SXd+2gHRl lHI.BuWjEdumaefhd4o6Sajyp9Hmh2IBoNTQBfMsuUDcvN+z0QRwY3r4Qp6b 5cpbtI+znp47KeL6XoEsuqJelE1zySBp5jwnRbq5SECHyR6h7fB.ktWASoTT W7lHqitN1gcVofQGC2C4K8rvnSPdBZkw2kvUgTrGNabKr037Z4apmrP8PNxN pYgp8vFcVs5+YIgp8vurAyujPsSiLblGwiQ9fA4wUoZ32AMYRL63Nd1Yx6gl 2YgjhN93CJHpSOpi5GaPGGYPiiysk2MzSNofSVvTEMlJfF6NPiwniFaU3FuI CNGMTsimUSGdfpH6H7+NU7iJqW1dyK73YNujebbmN0KkVublN7njsvIz7iJq WtSG+bjp7qt9kR3wcBwiqJ7Cbxviqy7x+kqJqWhyMSCLM3walwOJquOi3mIb 8RE3.mNygdv40xkmopKWWB+HCz3n2hMATN5sW6n2bsieq03812t4+.LXCiUL -----------end_max5_patcher-----------
@Christopher – the pretty basic usage is simply to trigger actions at a known time while using an easy and flexible controller for the time, and have it be available system-wide. This seems to me to be exactly the transport system – easy, well-integrated system-wide, and deals with time, except that it forces one to deal with time as bars/beats/units rather than providing the option to choose. It seems a real no-brainer to me to have this sort of flexibility, especially given that the internal timing mechanism is undoubtedly itself dealing with elapsed time in ms (or some other common unit); why not expose this underlying layer with a ‘mode’ attribute? In other words, I want all the power and ease of use of the transport/timepoint system without having to calculate the timepoints in bars/beats/units when I really want to structure my piece in time.
@Michael – Yes, I fully understand the intended usage, and have no problem with that. I simply see no reason it can’t do both, given that it, fundamentally, is used to structure events in time – so why not have the option to deal with standard time units as well as metrical musical time units? It retains all the power and adds flexibility.
@stringtapper – thanks, I’ve used such home-brew systems in the past, as well. There are certainly work-arounds to accomplish what I’m doing. It just seems a bit odd (not to mention counter-productive) to provide the ability to structure events in time (i.e., transport/timepoint) and then not allow the system to deal directly with time (elapsed time in raw ms, or hh.mm.ss, or whatever). Why have to build a duplicate and less well-integrated parallel system when the in-built system already exists to do something identical and extends to all the time-related objects?
In short, thanks all of you for the feedback so far. I’m still wondering what the ‘benefit’ is of NOT having the transport/timeline/etc. system include a mode to deal with standard time units.
While I understand your point of view, try thinking of it this way. There are two ways (or "modes", as you say) to measure time in Max: one is what you call "straight" time (I usually call it "clock" time, meaning that it refers to an agreed-upon, reliable clock) and what you call the "musical way" (I call it tempo-relative timing, because a given time in bars.beats.units will equal a particular clock time that depends on the stated beat tempo in bpm). The purpose of the transport object is to facilitate the musical way, so transport is always thinking of time in terms of bpm, timesig, and bars:beats:units. The purpose of the translate object is to provide that "mode" translation that you desire. Now, you might wish that instead of the translation taking place in a separate object, it could take place inside the transport object, but a) it’s actually more practical for that whole issue to by handled by a generalized translator object ’cause there are many situations in which translation is needed, b) transport’s job is to manage the tempo-relative timing, so it really doesn’t need to report clock time to you since you can translate any tempo-relative time into clock time and vice versa, and c) one could just as well argue that you’d have to work even harder to program around a transport object that reports time in different ways depending on some "mode" attribute (imagine an outlet that’s sending ticks and then suddenly starts sending milliseconds; you’d have to have a bunch of math objects to re-translate for you in that case anyway).
Most importantly, it’s one thing for a DAW like ProTools or Logic to provide a simple switch between different ways of expressing time, but compare that to the complexity of keeping track of tempo-relative time in a programming environment where people can write a program that changes timesig, tempo, or timepoints at any instant, can leap backward in time, etc., and does it all in real time and needs to stay as accurate as possible, and then you start to see why translation between the modes needs to be done constantly and is best done separately. The translate object does that for you by doing its translation every time the transport’s tempo changes.
Oh, and you make the assumption that, "It seems a real no-brainer to me to have this sort of flexibility, especially given that the internal timing mechanism is undoubtedly itself dealing with elapsed time in ms (or some other common unit)," but in fact that’s just the point: transport is not dealing with elapsed time in clock time, it’s dealing with it in tempo-relative time ("ticks"), and has to recalculate all timepoints, metro intervals, etc. every time something significant changes (such as tempo, most notably). The Max scheduler is the invariant clock that keeps track of scheduled events. The transport system (tempo-relative timepoints, etc.) are all managed separately from the Max scheduler. The Max scheduler, just holds a single scheduled event telling it, in effect, "Here’s the next time you’ll need to check back in to see what’s going on in the tempo-relative world."
So, I hope that long-winded rationale makes you feel a little better about the way DZ and company decided to implement it. If not, I guess I’d just reiterate my question above. Is your objection just on principle, or have you actually encountered something you want to do that you can’t do?
If I want to schedule timepoints in straight clock time, it’s easy enough to do, and if I want transport to report the current time to me in straight clock time, that’s easy enough to do, too. In the following example, when you start the transport with the toggle, it rewinds to time 0 and schedules a timepoint to occur at time 5.5 seconds. By default the transport’s tempo is 120 bpm, so we would expect that timepoint to happen 11 beats later, i.e., after 5280 ticks, i.e. on beat 4 of bar 3 (in the default timesig of 4/4). Now try changing the tempo and restart the transport. The timepoint object will do whatever it needs to do to translate the 5.5 second request into the correct number of ticks based on the new tempo, and it will still trigger at the correct time. Of course, transport will report different tempo-relative times for that instant, but the translate object will reliably translate the ticks back into clock time for printing.
----------begin_max5_patcher---------- 976.3oc0Y1sbhBCE.9Z8oHCydYWmj.DAup6ywNc5fZpltPfIDa6tc569BIfk 1FWAMgUuQMGfv47kyeI95zIdKyegV5AV.9IXxjWmNYhRTsfIMim3kk7xpzjR 0s4sJOKixkd2nulj9hTIeYhnrUHasRT9xG+NddqvGx4RdRFUcoeHXIosWguK KemLkJUuAX68K1rTMdFryLTx9iZFP38hqdbFu8oQMBKRjq1x3atWPWI01GIn 5Q.3f5ID3qGT8avc0OwaSmV+wMmKEnIRiXv+hACQJ6GiH0eogg0wvNNyHFPw WLXHVY+nXrxafbVXn5ctjJLYugG2dKRDUxkTw8TdxxTZWq9ir.2HUKR96Bp1 T7X0KA0gf7Mdf6rCez9GMQKgPGwG3UKe7wcBibEetdceBh5DdE5lrLB5yL9Z fLGHYYT.z..8gWLIbvXUIGc523PGQjhbgDrZmPTcYEVLULJ5RCJHcBXDL1IX Y6VPVFnrDjYr1L4hAGHBrSV2H7YQik6jxbtICNvrYgNTBhOlYn2qsvnNqsXn iLF7XZLQPKXKYzxxjMzu3lBW.WDNKDBAa2tHKaQ4du0TFmtJeGW1MOdWHL3z bGDOCqB.9XEH0sYoa81GY89GhtZKPpASjEJOdH2IIMqHG7MjItQt77Wz.Q60 PPpLGQmp+B84Jq7K.oPvdu3PWZDbxE.Nyz83H6skzCXzl5JB4ask+ZhZKO.T f+r4gUq6HbiqPn84QIMEXLj.OTlf+mUXtwhgFsfoIMJwE9IRQBuLMQRA2x3U cNt5WkfaqLsuTKpCyh+OkEoGgTnls2SbRCkJ7X.HWNMV2ryq1y237RsHy2rI 0zNIHCuHa+xjLrSovGagtxNTbQ0dnJxMW3HvZ9+N3nIZ56NL1MGMg+06Iag6 d1Dj.mkMsdu3lpzLTul3iPmludHMO4.+vzcYupS5TsDMUClajmpWlZeLe5ea PMg0x+HjKy2IV0ZmMTCf1qxqokRFOQxp1SXm6opYG.b+MsksdMk20qaMqr1Q TsV.MtZOD0AdL0IbTUG7QTmwSah6CbBFM0gzG0AeD0IisVUFnw8EGV2bZ375 OQg9yvMid+0Ltp+nAy.KnMehkAHEEaN6qv8Cb.K86g1GOZrD6.XhQZeRhBps zD4DOSLtO5u+oY.vvtwVpgtvDf8vDFuTU0Gn0wIJY7zGh88PaWY0Gxy6dntH dG42S8GMN3rOALX3.4YSHRjpALcxznH2fSqDva21dleD04T0FcGqIEEOQEkM SoRQp1.vi4h5gjaTCYb8P0L5InOwZu+no0y1aS+KkXSFM. -----------end_max5_patcher-----------
Hi Christopher, thanks for the in-depth reply.
My response will be rather simple, because your elegant solution both illustrates your point, and makes the case for mine, as well. If we can send the message "0:0:5.500 hh:mm:ss" to timepoint, and it responds at the appropriate time, then it’s already doing the translation in-house. Surely sending the realtime clock time out an outlet directly isn’t too much overhead, when clearly it’s already using it internally, as your example shows.
And I’m sorry, I don’t understand your point that transport is not dealing with clock time, but with tempo-relative time. In order to calculate it on the basis of tempo, it still needs to count time as it elapses, in order to report it and keep track of it, no? My point is that it’s already doing what I’m asking: it’s just obfuscating the ‘time’ behind tempo/bar/beat/etc. when it can do both simultaneously, because it already does; it simply isn’t reporting time directly. In an ideal world, it would report both.
Yep, I understand your point. But in the meantime, just put a [translate @in ticks @out ms] object after the ticks outlet of transport, and voilà, non?
Yes, indeed. And the hh:mm:ss command was also part of the missing link for me, though I’d read through the ‘time syntax’ reference pages a number of times, that bit for some reason eluded me. Thanks again.