How to get master tempo from lives transport?
Hi, … Title says it all really. Have been going through the new Mfl objects and patches and cant find anything? Am I missing something?
Yea, the bar along the top that says play, stop, tempo ect.
i guess he meant you should use the transport object to get tempo information.
Ok, fair play. Sometimes the simple answer is the last one you think of.
Could somebody please clarify how to do that? I’m trying to get transport info from Live into Max with no luck :-(
plugsync~ is a good utility object for use with live’s transport.
Plugsync~ and Transport have a lot in common. What are the pros and cons?
I find it easier to patch with plugsync~ as you don’t have to worry about polling it.
Apart from that, whatever you like…
I think the main difference is that metro+transport provides a tick counter.
This can be useful for handling different exact beat subdivisions.
Yeah you get raw ticks with plugsync~ too, and you don’t have to poll for them. This gives you transport location as well.
But with plugsync~ the transport location is represented by beats as float numbers, i.e. raw ticks/480.
I wonder if this makes a difference in practice regarding accuracy..
Neither plugsync~ nor transport are working for me. This is a max patch outside of live, not a maxforlive patch. Any ideas? Is there something really obvious I’m missing?
Thanks for your help.
thanks for the encouragement.
So I’ve changed my metro+transport patches to plugsync~, and it seems to work perfectly!
The attached example shows a synced 16th note counter.
Interestingly, plugsync~ delivers the current transport position also when not running.
So I’ve inserted a gate to avoid possible effects when the patch is loaded.
Any comments/improvements are welcome.
----------begin_max5_patcher---------- 434.3ocuU00aBBCE8Y3WQSebwQfxDk811eiEyREpPWfVhTxzYb+1W+.TzoQP QegK8zau8zy8PYisEbNeEoDBdE7AvxZiskkFRAXUO1BliWEkgK0oAYju4y+B NxLkfrRngSvBRC3BNSTR+gnlvy0wsFlWIxHBw5BhY+fPvrVqfgy0S.eaIEmA dmmE2TvBrHJkxR9bIIRXVr2zPYgkkOPE7QNikCl53tqjrpbJSteZVipAow5c Pd.d1CtOQCyzY5o.2ZaqdL51jjhrpjx0rne6qtPYB3niCKx3X8KYzxCA18Rq EbKJKBojz.i9hlnCmUY89ux5GdZoMb3jV8Is+h5.32LxxU32P2c+VTJlkP.6 c1c96vgy6TqRg5v396cBNsJ4eEpjY4WlrH+w5vtmclrmwm2nyQ77bByzafCW a9IvKN8sCathX.Zr9SuR6u+jK6+0ESd+F63+HoIjB+P0pjWsLp4H1rIf8bJl TJnLrfxYsRBcPNoz3XBqcaKmFWvkeGTyAvrS155JkPcfQAOTFotdFDbAJIuC A38XojaGnziSk75.iNxtcuoTPGnT3MvH4fs1+MUYRAO -----------end_max5_patcher-----------
Hi. I’ve just found the plugsync~ object. Why isn’t it called live.plugsync~? Does it work outside the M4L context? If not, I don’t understand this naming convention. I’ve lost some valuable time trying to receive tempo related info inside M4L. I was trying to parse the midiin messages to receive the MIDI clock from the host, but this information isn’t sent by MIDI.
My suggestion for the naming would be to create some kind of alias, as you already do, for instance, with the zl object or the jit.op objects: you can use zl.x or zl x, jit.op @op + or jit.+.
My suggestion, in order to more easily discover M4L specific objects, would be to also name it live.x: Examples:
midiin or live.midiin (as it can be used inside M4L or outside).
plugout~ would be just live.plugout~, because it is not used in other contexts. plugsync~ would also just be live.plugsync~. Now of course, I understand that for retrocompatibility, the original naming would have to be held.
P.S: this is not nitpicking… ;-) It’s only a suggestion to more easily find objects in their particular context.