playing 16th notes through transport and live.grid, timing sounds inaccurate
I've written an algorithm that takes the output of [transport] and converts it to a number between 1 and 64, which is then fed to a live.grid.
If I set all 64 semiquavers to 'on' and start the transport, the timing of the notes sounds a little off, when compared to playing semiquavers from a Live clip.
I'm using a straight Max patch here (not an M4L device) but I'm assuming that shouldn't matter.
Could it be my algorithm is inefficient? I've read that it's better to put your whole calculation into a single [expr] (as I have in this patch) rather than use a chain of math objects (which, by the way, produces the same inaccuracies).
I'd be grateful if you could try the patch on your machine and tell me if you experience the same inaccuracies, and also suggest how I might eliminate them. Thanks.
Edit: system details:
Max 6.0.5
OSX 10.6.8
Well, it turns out I get similar inaccuracies even if I just use a metro hooked straight up to a makenote.
So what else could the problem be? I'm sending the MIDI to the AU DLS Synth 1, the default synth on a Mac. If I had an external synth I would try it through that.
Or could it just be a problem with my system in general? I have a MacBook Pro 2.3 GHz i7 with 8GB RAM, so it's a very capable system.
It's the 16n in the metro - metros are horrible timekeepers in max, for some reason.
Here's how I usually handle it.
Thanks Wetterberg.
Your patch is an improvement, but I still think I can hear some smaller inaccuracies.
I wonder what would be a good way to test whether it's real or I'm just imagining it. Perhaps record some audio and then analyse it.
Any suggestions welcome for audio analysis tools that could do this.
load it up in Live. Trigger something like a square wave in operator. Record it. Measure the spaces between each note. Repeat.
Honestly that midi sample thing it plays drove me nearly nuts.
I was thinking more along the lines of a command line tool where I could feed in the audio and it would give me information such as average time between transients, and an error margin e.g. ±5ms
Indeed, any repetitive sound will drive you crazy after a while - thanks for bearing with it to help me!
I think my point was that it's rather difficult to even hear if it's tight when it grates like that - integrating it in a track and actually *using* it is really the way forward for me.
Anyways, I've been using the above method live and in the studio for a while now, and I've yet to see anything snappier in Max.
WETTERBERG !!! Thank you SO much for sharing your patch (where you mentioned the 16 and metro being a terrible time keeper).
I have been struggling with transport/metro combo for a problem i am working on and since using the timings directly from the transport raw ticks, life is easier agian.
:D
I actually feel that the "metro @interval 1 ticks @quantize 16n" works pretty great
I'll just resume this old conversation, that is still very relevant :,)
I'm in the last development stages of my sequencer and I noticed that playback in Ableton is delayed from the main Live clock source (I played the sequencer and a Drum Rack on two separate channels).
Before seeing this post, I was using a [transport] to get the current BPM from Live; then I converted the BPM into ms and input the result in the [metro]'s cold inlet. Here is the previous clock source in my patch:
After reading this post I changed to @wetterberg 's system, but the result is exactly the same.
Here is the current clock source:
Am I missing something here?
Please give a look at the screenshot of the recording of a 4 to the floor pattern.
Both systemlead to this result
Thanks!
I just solved it!
Intresting how you fiddle around for a couple of days with something without getting any result and then you find it out as soon as you ask for help.
Basically I was telling to my sequence to start from 0 instead of 1. That's because before the counter was set to 0 15 (16 steps) and when I changed it to 1 16 I forgot to edit the [ResetOnNextClock] subpatcher.
Now most of the times the sequencer is perfectly timed with Live, although once in while it goes back to the previous behavior.
I noticed that that's happening mostly when I start the playback with the spacebar; if I start it with the start button, everything is perfectly synced.
I hope that this can help somebody :)
also remember that M4L runs in the audio thread, which means the timing precision is related to the I/O buffer size