Metro and/or train~ in Max 6 and 7
Hi,
I've created a clicktrack patch in Max 6 for a project. I use a metro object which receives different timing values for each step in the clicktrack. As I want to sync this with audio files in the future and have both change playback speed simultaneously, the timestretch in Max 7 is interesting, so I started a new version in Max 7. Also I'm exploring the difference between metro and an msp object (tried train~ and phasor~), thinking this might give a tighter result and would sync better to audio. So I came up with a small test patch, and noticed some things I can't explain:
- in Max 6, a timer connected to metro always indicates exactly the same value as the time set in ms for metro, while train~ is switching between a small value above and beneath the frequency. When using click~ or a short sample, they stay synced, although with a short 'flam' sound. The difference disappears when lowering the signal vector size, disappearing when 1.
- using the same patch in Max 7, the timer connected to metro shows a slightly smaller value than entered in metro when ezdac~ is on. Also, when playing for a longer time with floating point values, train~ starts drifting away from the metro object, which it doesn't in Max 6. Decreasing signal vector size also decreases the difference, but it doesn't fully disappear.
I'm not sure which option I should use. In this patch it looks for me as if metro is more reliable. But I don't understand the difference in result for metro shown by the timer object in max 7 when ezdac~ is on or off and how this influences correct timing for long playback sessions and if it will stay in sync with an audio file.
I've added the test-patch to this message.
I haven't fully taken a look at what you are trying to do, but I would just recommend that you make sure that both Overdrive and Audio Interrupt are on.
Hi, yes, both are on. The audio settings are the same in both 6 and 7
Added transport to the equation, and same result: both metro and train~ sync in max 6, while metro starts drifting away from train~ and global transport in max 7. Have to withdraw my previous conclusion: it seems that - although the timer shows slightly jumping result - using msp is a better option. But why the difference between max 6 and max 7?
Here's the patch with transport added.
Vincentc,
I can see this here. It looks like timer is reporting approx one vector size less than the metro's interval.
We did change a bunch of things about how the audio scheduler time works and how it is updated. We will have a closer look at this to see if there are some real-world problems here.
Hi,
I also think the problem is related to metro. If you check with audio playback in the test patch, and against transport, metro gets out of sync in a similar setup in Max 7, but not in Max 6. As in the clicktrack patch I'm working on accurate timing is relevant, metro becomes useless in this way. nevertheless, I was figuring out if msp-objects could replace metro, so maybe for the moment that's the best option.
I'm sure the problem has nothing to do with [timer]. It seems that audio thread "interrupts" at wrong moments or there is some issue with samples to ms calculation.
While it's of course possible that there's a bug, my own testing doesn't indicate that there is one, and some arithmetic (and understanding of the relationship between the Max scheduler and MSP) shows that the sort of differences you're seeing are to be expected. Unless your time interval specified for train~ is an exact multiple of the duration of one signal vector, there will always be a discrepancy between the moment at which train~ reports a bang (by finding a 0-1 transition in a signal vector) and when metro reports a bang (because it was scheduled to occur).
In this example patch, train~ is requested to report a bang every 1000 ms. But, if you have a sample rate of 44,100 Hz and a signal vector size of 64 samples, then a 0-1 transition in train~ will occur once every 689.0625 vectors, which means a discrepancy of 1/16 of a signal vector between when you'd ideally like for a bang to come out and when it can come out given the fact that the vectors are calculated once every 1.451247 milliseconds. Thus, the location of that 0-1 transition moment occurs at a different place within the signal vector each time. As it moves through the signal vector 1/16 of a vector at a time, you get 15 reports that are about 0.0907 ms early, then 1 report that's about 1.36 ms late. In my tests, this expected result occurs in Max 6 and Max 7.
Hi Cristopher,
when running your example in Max 7, looking at the timer output of metro (if audio is on) I notice that the timing is *always* early, ie. never compensated like the train~ output. So I think it clearly demonstrates a bug related to metro in Max 7.
I agree now, Broc. I inadvertently had 'scheduler in audio interrupt' off in Max 7 when I was testing, but had it on when I was testing in Max 6. With 'scheduler in audio interrupt' on in Max 7 I do now see the metro result you're describing. The train~ object behaves as I described in both 6 and 7 with 'scheduler in audio interrupt' on.
Hi, thanks for clarifying on the train~ behavior, I figured out it had to do with the vector size - as the difference diminishes when this is lowered - and now I can understand how it works. Does this theory also works for the metro object? And can it explain the difference between max 6 and 7? Or is it indeed a bug with metro?
And back to one of my first questions: for my clicktrack patch, timing needs to be as tight as possible (definitely on the long run), and if I would like to sync it to an audio file, should metro do the trick - without the bug - or is train~ better here? If I look at the test patch in Max 6, it seems that metro is more constant than train~, although train~ only has a minor difference and compensates for it after running through the cycle you described.
In Max 7.0.0 you need using train~ since the metro bug leads to drifting.
Hi, thanks for all the replies earlier on this topic. I've started work on my patch again, but still have some questions due to the difference between both metro and train~ objects. The patch sequences irregular measures, and thus frequently changed the time of the train~ object (sometimes every bang). It seems to me that the compensation value as Christopher described, changes together with the speed, so I conclude that this will mess up syncing with audio in the long run, for there is not always a correct compensation. This points me again to metro, because - bugfree - it seems to work more correct. Or am I again missing something here? Thanks for helping out!
I guess that fast speed changes of train~ or metro are both problematic. So it may be better to run constantly at highest speed and use counters for deriving slower speeds.
Hi Broc, I suppose that would work for regular cycles to derive them, but as the patch is used to sequence irregular meters (beats of different length with tempo changes and different subdivisions for each beat) it's difficult to find a common speed. The change doesn't happen at short time fragments, but it changes often. Smallest time intervals are still around 30 ms. Still seems problematic to you?
Yes, I think so. In particular, since changing the speed may need some time to take effect it would have to be triggered a bit early which seems difficult to handle.
Hi Broc, thanks for keeping up. I've included a small example of how I organized this in the patch (with train this time). I've checked with timer and it seems that it only reflects a small difference according to the vector problem, but doesn't suffer from triggering. I had a problem with recalling different values from a pattr (increased latency), but changed it so that new values for next beats are in fact recalled and calculated one measure before. I store the new values and push them after the last beat for a measure has been played, and thus it more or less functions the same as this patch if you change values in between beats. Can you illustrate the problem you had in mind yesterday? Thanks!
Well, I think you actually solved the problem that I had in mind (early trigger).
PS.
The metro bug appears to be fixed in Max 7.0.1.
Hi,
Just to make sure: scheduler problem with metro seems to be solved in the new update.
Vincent