MIDI delay recording
Thanks for your responses in this lengthy thread Amaury - I appreciate your position and that certain intrinsic decisions as regards Live's MIDI implementation are outside your control but I do feel this issue is of core importance to Live's development and the continued usage of it in my studio.Amaury wrote:I do not want to go into a debate again, as it brings more confusion than anything else. We are not saying that we are right and the world is wrong, I am only trying to tell how it works now. The rest is up to other people, and I can't tell what decisions would be made.
Okay - unless I've misunderstood you, in which case please do correct me, you've actually nailed the argument perfectly here:Amaury wrote:Monitoring should only be ON for MIDI recording if you monitor sound through Live (the played MIDI data plays a soft synth). In that case, what you hear while recording is what get on play back. No theory, just straight behaviour: if you manage to play in order to hear the sound on the beat, the sound will be on the beat on play back.
"if you manage to play in order to hear the sound on the beat"
Users shouldn't have to 'manage' - most of them I'd imagine are skilled enough musicians that, when given a beat, they can play to it. The issue is, as I see it, unlike an instrument with a static inherent latency, ie: a piano, guitar etc, where a player can consistently adapt their playing to that value, Live's latency is not static but a variable value based on ASIO buffers, PDC, computational overheads and, as you mentioned earlier in the thread, also subject to CPU jitter.
Hence players are having to deal with a continously variable latency in order to, as you've put it, 'manage to play'. In my experience, even when dealing with low ASIO buffers (128), any project with a reasonable number of VSTi tracks suffers greatly whenever I want to add another and, in most cases, I'm literally having to resort to programming the invdividual notes in even for the simplest of parts. I cannot continously adapt my playing to compensate for latencies, even with a low 128 buffer, that are sometimes in excess of 100+ milliseconds & variable. A 128 ASIO buffer at 44.1 should be about 2 milliseconds!
Live is the only DAW I've ever used that 'functions' in this manner and, despite the wealth of creative options it offers, unless something is done to address this issue I will have to move on as regards my preferred choice, and my recommendation to my customers, of DAW host as this particular issue is costing me, & them, both time & effort
Hi,Nod wrote:Okay - unless I've misunderstood you, in which case please do correct me, you've actually nailed the argument perfectly here:
"if you manage to play in order to hear the sound on the beat"
Users shouldn't have to 'manage' - most of them I'd imagine are skilled enough musicians that, when given a beat, they can play to it. The issue is, as I see it, unlike an instrument with a static inherent latency, ie: a piano, guitar etc, where a player can consistently adapt their playing to that value, Live's latency is not static but a variable value based on ASIO buffers, PDC, computational overheads and, as you mentioned earlier in the thread, also subject to CPU jitter.
Hence players are having to deal with a continously variable latency in order to, as you've put it, 'manage to play'. In my experience, even when dealing with low ASIO buffers (128), any project with a reasonable number of VSTi tracks suffers greatly whenever I want to add another and, in most cases, I'm literally having to resort to programming the invdividual notes in even for the simplest of parts. I cannot continously adapt my playing to compensate for latencies, even with a low 128 buffer, that are sometimes in excess of 100+ milliseconds & variable. A 128 ASIO buffer at 44.1 should be about 2 milliseconds!
Live is the only DAW I've ever used that 'functions' in this manner and, despite the wealth of creative options it offers, unless something is done to address this issue I will have to move on as regards my preferred choice, and my recommendation to my customers, of DAW host as this particular issue is costing me, & them, both time & effort
Thanks for your input. I'd just add a couple of points. For real instruments, you don't always have a static latency: the latency of a piano for example is subject to the dynamics: the hammer takes more time to hit the string if you play a soft note - but of course piano players develop that specific skill. For an electris instrument such as a bass or a guitar, the distance to the amplifier counts as well. My guess is that the main thing is you can't 'think' about it if you play the piano, or an electric guitar. You can't even 'look' at it. so people manage to play something that's pleasing to their hearing. I'm quite sure that if you add some hardware effects, the latency may also change.
On the computer, the latency of a given plugin is static, given that you do not change your audio buffer size every morning (because that also gets into the picture). In Live in particular, if you monitor a track, it is taken out of the PDC engine, so that you don't experience the latency of devices in other tracks. So, playing with the minimal possible buffer size, and rather low latency instruments, the experience of playing the keyboard should be acceptable (and that's the same for any computer based solution, no other way around).
Regards,
Amaury
Ableton Product Team
-
mercyplease
- Posts: 1003
- Joined: Sun Feb 05, 2006 2:22 am
- Location: Sent back to hell
Then thats the obvious conclusion. its obvious this is a problem, anyone with one years experience on a daw recording external audio would notice this straight away.icedsushi wrote:It's not like the wheel is being reinvented or new technology has changed this issue or anything. Software companies have already had solutions for dealing with latency for years now so it has already been figured out long ago. Apparently Ableton is the only one that has a different philosophy when it comes to this.
HA HA HA 
Why would they have fixed it in the latest update if they haven't even acknowledged that it's a problem yet?
Should we just give up with this thread and continue to pencil draw and nudge midi notes by hand as the solution? With all due respect to the Abes, I'm loosing hope that we will ever going to be able to persuade Amaury and the crew that the midi timing isn't right.
Should we just give up with this thread and continue to pencil draw and nudge midi notes by hand as the solution? With all due respect to the Abes, I'm loosing hope that we will ever going to be able to persuade Amaury and the crew that the midi timing isn't right.
-
Synthbuilder
- Posts: 523
- Joined: Thu Nov 10, 2005 8:42 am
- Location: Cumbria, UK
- Contact:
In summary Live records what you hear and not what you play. Everyone else, it appears, records what you play and not what you hear.
This is the problem. Its an historical issue. If Steinberg had chosen the 'record what you hear' method all those years ago when Cubase VST first popped up, we probably wouldn't be having a discussion on this.
But really there is no right answer. In an ideal situation we should hear the notes as we play it, so either midi timing method would work perfect. The problem there is always latency - so which is the correct method? Neither.
However, the best way for any host to deal with this is to offer both options. What we need is a little switch in the options menu that selects between 'record what you hear' and 'record what you play'.
For me, I would have it record what you play for almost all situations.
Underlying all this are other midi timing problems, the worst being the rewire latency problem. But we'll save those for another thread.
This is the problem. Its an historical issue. If Steinberg had chosen the 'record what you hear' method all those years ago when Cubase VST first popped up, we probably wouldn't be having a discussion on this.
But really there is no right answer. In an ideal situation we should hear the notes as we play it, so either midi timing method would work perfect. The problem there is always latency - so which is the correct method? Neither.
However, the best way for any host to deal with this is to offer both options. What we need is a little switch in the options menu that selects between 'record what you hear' and 'record what you play'.
For me, I would have it record what you play for almost all situations.
Underlying all this are other midi timing problems, the worst being the rewire latency problem. But we'll save those for another thread.
heh i found seems the only way to avoid notes-shifting after midi-recording - just NOT TO SWITCH OFF the arm record button on the recorded midi-track... the monitor shud be switched to AUTO. it works well when you're listening or rendering - just as you played while recording - but if you want to freeze that track or record the audio from it - the shifts will appear... ))
it will not solve the whole problem but it can save some nerves for users while the ableton crew is thinking - to do something with that shit or not... ))
it will not solve the whole problem but it can save some nerves for users while the ableton crew is thinking - to do something with that shit or not... ))
hey this topic is still aLIVE! )))
found a simple way to record audio from a previously recorded VST synth midi session with the notes recorded as-it-was-played-and-heared without any COMPENSATION SHIFT...
1 - the record button on the recorded midi track shud be still ON
2 - send that midi track to new RETURN
3 - create a new audio track to record from that RETURN
4 - shift-click on the arm-record button on that track and record it
5 - voila! )) the recorded audio track will have NO that f*kin COMPENSATION SHIFT.
but if you will record audio directly from the midi track to the audio track - the shift will appear!...
p.s. the vst-effects on those tracks, and on that return, and on the master, and also the global latency settings shud be the same during both recordings to avoid more little shifts...
found a simple way to record audio from a previously recorded VST synth midi session with the notes recorded as-it-was-played-and-heared without any COMPENSATION SHIFT...
1 - the record button on the recorded midi track shud be still ON
2 - send that midi track to new RETURN
3 - create a new audio track to record from that RETURN
4 - shift-click on the arm-record button on that track and record it
5 - voila! )) the recorded audio track will have NO that f*kin COMPENSATION SHIFT.
but if you will record audio directly from the midi track to the audio track - the shift will appear!...
p.s. the vst-effects on those tracks, and on that return, and on the master, and also the global latency settings shud be the same during both recordings to avoid more little shifts...
I f*(#&in hate this thread!! stop bumping it 
Anyone who has no problem with using extra tracks should just create the second track with it's monitor off and record MIDI to that one. At least then you only have two tracks instead of 3 like you suggest..
Anyone who has no problem with using extra tracks should just create the second track with it's monitor off and record MIDI to that one. At least then you only have two tracks instead of 3 like you suggest..
actually it's a switch on the track, and it's called 'monitor'offer both options. What we need is a little switch in the options menu that selects between 'record what you hear' and 'record what you play'.
Yay! There is hope!
From the new Ableton Live 7 announcement....
http://www.ableton.com/live-7-whats-new
From the new Ableton Live 7 announcement....
http://www.ableton.com/live-7-whats-new
I guess there is a MIDI timing fact sheet coming soon.Improved MIDI Timing
The MIDI engine has been reworked and we were able to significantly reduce timing error (jitter) of recorded MIDI.
-CitrikSystems-
-minimaltechno-
-minimaltechno-