Better timing of live.step...
Trying to perfect the timing of a live.step device. No matter how I configure the live.step interval, or the metro interval and quantize I am seeing a very consistent delay in the actual timing. Here's the simple patch I have been experimenting with...
I set up another channel to receive the incoming midi from this device and without fail, this is the kind of delay I see (pictured in attachment).
I know it's never gonna be perfect. That's just the nature of these things. What I was wondering was if there was anyway to compensate at all for this, or better yet for my case, get the notes hitting slightly earlier than they should? Perfection is not needed, but I would like to play around with the timing a bit more and seem to be stuck with this.
Your picture doesn't show how far you've zoomed in? We can't really tell what the delay is based on that picture.
Zoomed all the way in so the delay is extremely minimal. Really shouldn't have posted the picture now that I think about it.
What I'm really wondering is if there is a way to play around with the timing a little more. Like I said, notes hitting slightly earlier than the mark would almost be preferable for my particular application. Messing with ticks and note values in any formation isn't getting me anywhere.
I'd do something with phasor~ 1.0.0 @lock 1. (Away from computer; pardon syntax)
That way you get a phasor~ that's synced exactly to the bar. From there, you can create any offset you need via the following: +~ offset_pos_or_neg
%~ 1
+~ 1
%~ 1
Subdivide with rate~ as needed to get a a stream of phasor~s. Use delta~, abs~, >~ 0.5 into edge~, and use the left outlet in lieu of metro. This should reduce global jitter. (There is a way to get swing out of the phasor representation as well)
Alternatively, if the only problem is global latency, you might try adjusting the device's latency compensation. (Not sure if this is only for audio devices)
that's an inherent problem with clocking the way you're doing.
Basically you can't compensate backwards, if you're using transport, since you need to recalculate a lot of stuff that way.
try this on for size - if I've done it right it'll let you offset the named transport from the global transport, to compensate for even very slight lag.
essentially what I'm doing is subtracting from the tick count *before* it gets converted into timing information for the live.step.
Awesome! Thanks guys. Gives me some stuff to tinker with this afternoon!
Still struggling with this. Unfortunately wetterberg, had no luck playing with your example.
Does anyone have a working phasor timing object I could play around with. Can't seem to get one functioning no matter what I do. Even followed the "Programming in Max For Live" tutorial on the live.step object.
When you record the output to a midi track, is your device sitting alone on tis track ? It has to be. Make the test by adding a 2nd device behind it, whatever it is, and you'll notice a delay. Doesn't mean the timing will automatically be perfect because there can be other problems in your device but this is something to know...
If delay compensation in Live is enabled, insertion of devices should not effect the timing at all provided that the live.step device is always the FIRST device in a chain (because Live's delay compensation doesn't work for synced devices).
Delay compensation is enabled. Is this just an issue with sending control from one track to another in Ableton?
Also played with device defined latency. No luck.
Just can't pin it down.
What do you mean with 'sending control'? In my experience any communication between tracks aside from standard midi/audio routing introduces some unpredictable delay which is not compensated.
By control I mean what I'm trying to do in the original post...send midi note data from a live.step on one track to another track to be recorded.
^ in this case the timing should be ok.
I've just checked the factory M4L step sequencer and get recorded notes with accuracy of about 1ms.
Ok, looks about to be what I'm getting which is the problem. Unfortunately that 1ms throws off what I'm trying to do in the end.
So the question is, will a live.step controlling a device or calling api functions on the same track where it resides have that same 1ms delay?
Can test myself, but it will have to be when I'm finally back to my computer.
I don't quite understand why a tiny delay of 1ms could be a serious problem in the midi world.
Working on reprogramming my Megaloop device from the ground up. It's a step sequencer for triggering clips. (Don't look inside the original unless you want to shudder in horror at the incredibly sloppy patch work.) From day one the timing of it has driven me nuts. Been able to sort a lot of other bugs and inconsistencies, but the timing has had me scratching my head.
What I want to do is be able to use Lives 1/32nd note clip launch quantization. So notes coming from live.step have to hit a bit early but don't have to be perfect.
Think I have somewhat of a solution worked out as of last night.
A metro is driving a counter. Counter goes to a >= to object and when it hits a certain number, it opens a gate which allows the metro through to transport which kicks off the live.step.
Kinda silly, but it's the best I can come up with with my still incredibly limited knowledge. Sort of a buffer or pre count.
Important part is, it works. Had live.step start triggering clips dead on 2nd bar mark.
I don't know. It's a fun project to waste time with. Any other suggestions are welcome.
Obviously, to trigger anything ahead of the first bar is not possible (law of cause and effect) but only ahead of later time points like eg. the 2nd bar mark. So I think your solution is basically ok.