seq midi drifting out of sync

    Jun 27 2011 | 9:19 am
    this might be close to a double post, i admit. it is the same problem as described here:
    but i have come closer to the problem and i realize it is not a jitter problem, it is a problem with seq. i posted the other thread in the jitter subforum, this one now goes in the max/msp subforum.
    when i play back a midi track exported from pro tools with the 'seq' object the midi information is drifting out of sync with audio + video. quite a lot.
    is there a way to make the seq run tighter? perhaps in with timecode from the video? or with use of the 'tick' messages triggered by a metronome?
    the midi file was exported from protools with a session running 120BPM. the same behavior happens if i record the midi data with the seq object, and play it back afterwards.

    • Jun 27 2011 | 10:08 am
      There is a small patch a the bottom of this topic that may help you:
      I don't know Jitter well, but I suppose you could regularly ask its position with the gettime message to send seqtick messages as regularly as possible (48 messages / second). But I may be wrong...
    • Jun 27 2011 | 1:07 pm
      gettime looks promising... but it only sends a msg every second. how would i go about getting 48 ticks/sec out of that?
      ps: for reference: i added my current patch to this thread:
    • Jun 27 2011 | 1:37 pm
      gettime is as fast as you send it to I can get values every couple of ms.
      But it may indeed not be the right way... What if you sync your movie and your seq to a soundfile?
    • Jun 27 2011 | 1:44 pm
      hm... this is interesting. perhaps i could even have that soundfile as a separate track in QT, routing it to max via something like soundflower?
      but please explain, what is the sync that is coming out of an audio file? is it a tick on every sample, so sample rate based? what should this audio file contain?
      and how is this more stable than just making some metro with the right tempo?
    • Jun 27 2011 | 1:59 pm
      There is no sync from an audio file per se, but its speed is much more accurate than Max' internal scheduler.
      As you saw in the other topic, the position in a soundfile is given as a signal (it doesn't depend on Max' scheduler), so it's refreshed at every vector.
      To get those 48 ticks every sec., you could also imagine to have a sound file embedded in the QT movie with 48 digital clicks every second and analyse this file (with a change~ for instance). Unfortunately I see that spigot~ is only stereo.
      Not sure soundflower is the right way to go for an installation...
    • Jun 29 2011 | 9:04 am
      thanks for clearing this up.
      max is truly a different way of programming. but i like it :)