jtay

I have a question. A while back I downloaded the trial version of Max to see if I could write a custom piece of software for live-looping. Max came very close to being able to do what I wanted. I was using the "seq" object to record and play back my MIDI loops. However, I found out that the timings of all the MIDI events recorded by seq were rounded to the nearest millisecond. This caused my loops to not sync as well as I would like.

I have since learned that there is a "seq~" object that functions similarly to seq--it can record any messages, including MIDI messages if you convert them into regular messages first. I also heard that the seq~ object has "better" timing than the seq object. I would test this, but alas my trial period for Max ended a long time ago. Is this true? I would rather not purchase Max unless I am sure that it can do what I want.

seq-vs-seq-timing-question

Yes, seq~ can be controlled using a phasor~ (or other 0-1 signal) and its timing is substantially better.

If Max uses a signal vector of 64 samples, the resolution at 44.1kHz would be about 1.5ms.

So it seems the timing of seq~ is not better than seq.

If Max uses a signal vector of 64 samples, the resolution at 44.1kHz would be about 1.5ms.
So it seems the timing of seq~ is not better than seq.


I think the timing he's referring to also means overall accuracy, not just within any given event window. While there is a window of 1.5 ms for the event in the case you mention, you're guaranteed the overall position of that window relative to the incoming signal's value, which is not the case with seq.

Seq is prone to be subject to cumulative error (drift) because it is using an interval-based system. Seq~ is not affected by this since it's using absolute positioning and running on the MSP clock. If you set them up side by side, you should see seq deviate quite a bit, since it's doing it based on interval. While the local events may wiggle a little (and 1.5 ms is a little considering that some hardware synths have latencies of 4 ms between keypress and sound), the loop length doesn't change over time because of that.

If local timing is absolutely critical (and I'd encourage you to test it to find out), you just wrap the whole thing in a poly~ and shrink the signal vector inside of that. I'm not sure of the usefulness of this, since if you need that sort of timing accuracy, it's probably something worth doing in the signal domain by that point. There's also going to be MIDI latency with your input, so events will probably be at least 1 ms apart anyways.

Seq~ is what I use for control-rate loopers, and I've been pretty happy with the results. YMMV, but I think it beats seq hands down.

I think the timing he's referring to also means overall accuracy, not just within any given event window.  While there is a window of 1.5 ms for the event in the case you mention, you're guaranteed the overall position of that window relative to the incoming signal's value, which is not the case with seq.  

Seq is prone to be subject to cumulative error (drift) because it is using an interval-based system.  Seq~ is not affected by this since it's using absolute positioning and running on the MSP clock.  If you set them up side by side, you should see seq deviate quite a bit, since it's doing it based on interval.  While the local events may wiggle a little (and 1.5 ms is a little considering that some hardware synths have latencies of 4 ms between keypress and sound), the loop length doesn't change over time because of that.

If local timing is absolutely critical (and I'd encourage you to test it to find out), you just wrap the whole thing in a poly~ and shrink the signal vector inside of that.   I'm not sure of the usefulness of this, since if you need that sort of timing accuracy, it's probably something worth doing in the signal domain by that point.  There's also going to be MIDI latency with your input, so events will probably be at least 1 ms apart anyways.

Seq~ is what I use for control-rate loopers, and I've been pretty happy with the results. YMMV, but I think it beats seq hands down.


Is anyone interested in posting an example of using seq~ to play back a coll?

adapted from rodrigo's seq~ abstraction:


You have given me hope in this deep, dark, world I'm have been in.

Hopefully, I can figure out how to use it with MIDI events that stat in sync with an audio signal across several minutes of time.

I promise to post any successful results back to this forum once I am successful.

seq vs. seq~ timing question