[hostsync~] vs. [transport]

    Dec 02 2009 | 4:09 am
    Which is best to sync a Max instrument to Live's transport?
    The problem I'm having is that [transport] needs to be constantly banged to have it's transport state output, and the easiest way to deal with this is with a [metro]. But when Live's transport stops so does the [metro] and so the off state of the [transport] does not get output.
    The reason I ask about [hostsync~] is that it does not need a bang to report its values. So should we still be using [hostsync~] for tasks like this or is there a better way to do it with [transport]?

    • Dec 02 2009 | 5:44 am
      Hostsync~ only works with the rewire driver - which is not used in MFL.
      You can get transport state in MFL easily.
    • Dec 02 2009 | 7:47 am
      Ok, thanks for that Andrew. Your example works great for the on/off state. I think my confusion came from the fact that hostsync~ [i]was[/i] working in a M4L device while I was attempting to port the ReWire guts to transport-based guts.
      If you don't mind indulging me a bit here... I think I was conflating some terminology here, but one of the things I was trying to do was get the bars.beats.sixteenths position from the transport when the transport is not playing. When you click Live's stop button it resets to 1.1.1, but you can't get this info from a transport object by banging it with a metro because the metro is run by Live's transport to begin with. I see the function "get_current_beats_song_time" under the Song class, but I'm just not far enough along with the API to know how to implement that. Should I go down that path or is there a simpler way without using the API?
    • Dec 02 2009 | 7:03 pm
      How about disconnecting the metro from ITM?
      so use
      metro 5 @active 1
      for a metro with a 5 msec granularity which just bangs away constantly. Or maybe you could use the "transport has stopped" bang from my patch above to trigger a final location bang.
    • Dec 02 2009 | 7:27 pm
      Thanks again Andrew. The metro solution is the one I came to last night. (Although I only put "@active" in the object and it worked the same.[?])
      I'm porting Lo-Fi Massahka's DyNAmic instrument for Lemur/Live/Max into a M4L device and the instrument has transport control on the Lemur that also needs to update when transport, tempo, etc. is changed via the mouse.
    • Dec 02 2009 | 7:57 pm
      Excellent - looking forward to checking that out!
      Yeah, in order to force updates of tempo you may need to use the API. If you need to keep your Lemur in sync I guess you would need to send it ITM ticks, but if you just want to keep it informed of the value of tempo, you might be able to use