Anyone?

Thanks

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.

@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-----------

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.

Thanks!