Peter Nyboer

This simple patch demonstrates a problem I have if I speed up the tempo of transport. Not all "ticks" values are reported, so not all my data is retrieved from the sequence. How do I solve this problem? I'm a bit stumped. 

playing-back-a-sequence-with-transport-at-faster-tempo-than-was-recorded

Yes, but I believe it must be written as [metro @interval 1 ticks].

The brute force method of running a metro as fast as possible in hopes of hitting all possible points in time is rarely efficient or advisable. In this case, running a metro at an interval of 1 tick means 960 bangs per second, only a very few of which are actually useful.

The mtr object is made for recording messages and playing them back in the same rhythm as they were recorded:

But mtr is not really designed to play back at different rates. However, you can do it with a little ingenuity:

And if you really need to have your recorded messages be synchronized with precise moments in the transport's timer, it's probably better to record the event time along with the event, and then use those time tags to play back the events. But you shouldn't bang every possible tick looking for events. It's better to use the time tags themselves to generate the events at the desired time. Here's one way. (I don't guarantee that it's the best way, 'cause I threw it together rather hurriedly, but hopefully it illustrates what I'm suggesting, which is to let the Max scheduler take care of the timing for you, since that's what it's designed to do.) The transport must be on, of course, for this way to work.

Thanks much for the alternative. I was a bit wary of using metro at the ticks 1 rate, but it seemed to work. The mtr is out of the question for a variety of reasons, but the last example using [timepoint] is illustrative. I was only recently made aware of [timepoint] and hadn't really absorbed its usefulness in this context.

playing back a sequence with transport at faster tempo than was recorded.