Sync two computers over usb

    Jun 19 2022 | 11:03 pm
    Have two MacBooks running indentical patches attached to the same interface (iConnectAUDIO4+) witch allows for easy audio/midi intercomunication Via USB ports 1 and 2. Looking for a way to send sync from one to the other over usb (no network/WiFi). currently sending stop/start and tempo information via midiout of master MacBook to midiin of slave. the timing is good and does not drift but wondering what the best way to do this is as you can‘t send values greater than 127 with midiout and would rather use proper midi sync. Assuming sync~ is the way to go but can’t figure it. Also is there an object to send non midi max messages of any type over usb?

    • Jun 20 2022 | 6:08 am
      You need midi beat clock for midi sync. send :
      on receiving side have a look at rtin object if MIDI sync is what you need.
      help file shows only seq example , but you can do much more than that, using counter based bar:beat:ticks progress or sync transport (which I dislike) to incoming clock. sync~ is for audio
    • Jun 20 2022 | 11:28 am
      If you ever find an answer to your last question, I'd love to know! Not being able to send a MIDI reset (0xFF) through a MIDI output in Max has been a major pain in the neck for me!
    • Jun 20 2022 | 3:51 pm
      Assuming you have max on both sides you can send all manner of messages over midi, too.
      just remember you don't need to conform to any sort of standards in transit. You can deconstruct and reconstruct as you wish, even sending sysex if you should wish.
      honestly though, the best method I've ever found is still Ableton Link. You need the Link package I think, but two machines synced over an ethernet connection is ROCK solid, and much more flexible in terms of control on both sides. Even using wifi between the machines should be real tight.
    • Jun 20 2022 | 5:47 pm
      wetterberg- have used link.session but was crap on my wifi regarding start timing of the 2 transports and would like to avoid creating ad hoc networks etc. Can the Link package be used in a hardwired scenario using usb to send sync without using wifi/ethernet? thanks, 2 computer setup broke my brain a bit.
      source- thanks will try that next
    • Jun 21 2022 | 10:10 am
      @andy - sending of 0xFF / 255 was never a problem in Max
      What you use on receiving side, and how that gets parsed is a different topic. --------------- @Brian - you are mentioning midi so I think midi clock is your best bet to sync midi over USB, but honestly, I never had any problems with network & midi, even on large > 20 computers sessions, but ... I never used crappy ableton or Apple's midi over network stuff. I would try IPmidi - freeware till Mojave (version 1.7.1) . If you use WiFi for Internet etc, you could still link 2 MacBooks using ethernet cable , give them fixed IP addresses, and use that for your music needs, independent of wifi. Then, as Wetterberg suggested you can use any kind of messages. P.S. to avoid missunderstanding ... if you use MIDI you MUST conform to midi message standards. You can't send just any number in any combination. Otherwise midi pipeline could get corrupt, and stop communicating correctly.
      What Wetterberg probably meant is that once networking is established, any kind of protocol can be used, like raw UDP for example.
    • Jun 21 2022 | 10:52 am
      @SourceAudio Thanks. I don’t know how many times I tried it but I never got anywhere. Time for another trial, me thinks?
    • Jun 21 2022 | 11:22 am
      I can confirm that on windows at least loopMidi receives it same as on the screenshot midiout > rtin. But ... 255 being status byte for meta midi messages had some problems with transfering midi text, but last time I checked that was way back in max 5. Sending status byte , text id, message length and then data allways stripped last char from message, appending it at the beginning of next one. At that time I gave up metadata and transfered text message in sysesx string. P.S. had to take care that ascii code stays within 0-127, so some chars were not possible to send.