Midi record timing still not right in 5.0.3b4

[madlab]

OK
Let me reiterate: The Overall Latency in Audio Prefs reads:
14.0 ms + 12.0 ms + 0.00 ms = 25.9 ms
If I change it to read:
14.0 ms + 12.0 ms + -25.9 ms = 0.00 ms
Then I can record MIDI clips with monitoring set to AUTO or IN without inducing the aforementioned delay in the MIDI clips
BUT.....
entering this negative setting in the Overall Latency adjustment introduces a recorded delay when recording audio clips (no matter what the monitor setting is), so thats not-so-good.

Is the last sentence true ? I always thought that if monitoring is set to 'off', my audio timing would be ok.

[Synthbuilder]

Perhaps I am just reiterating of what has been said here, but this is the way I think it should be done:

Recording of midi should be identical whether in IN, OFF or Auto modes. Midi data should be compensated only on playback. After all, the amount of pre-delay that any track has, will be affected by the plugins used, and you can change the number of these after you have recorded the data.

The amount of predelay applied to a track on playback should be shown in the track delay box. Right now, they all say 0mS. They should display the value used by PDC or other compensating method.

Each track delay should be able to be individually set. Also, it can be manually be altered should the user require. Any one track should also not affect the playback of other tracks. Currently changing the track pre-delay on any midi track will affect playback on any other rewire midi output!!!

[CopyRightJustice]

A workaround for the recorded midi latency problem is to create two tracks with and without monitoring yes?

so why can't this be done behind the scenes automaticaly?


followed this topic a while ago,not so fresh now.Just got up still tired,am I missing the point?

[Johnisfaster]

no offense but this sounds like something a person with no programming experience would say. problems are not so easily fixed.

[Johnisfaster]

is each note recorded at a different buffer? cause what I always do is record a sequence and then highlight it and drag it to the left till it starts on the downbeat(or whever it's supposed to start)

so is it late the same amount on each note or does the latency vary from note to note?

[diverdee]

Johnisfaster: It's late the same amount.
For example if latency in preferences is set to 13ms, so overall latency is 13+13 = 26 then the midi notes will be 26 m/s late unless a negative value of -26 is manually added to the latency to give an overall value of 26-26 = 0 the notes are then placed correctly.
So midi notes monitor correctly (in time) but are then recorded late with a value that corresponds to the overall audio latency - hence to fix the problem they need to be automatically retroactively moved back by a positional value equal to the overall latency (26m/s in the above scenario).
They will then monitor in time & be recorded in the right position.
Right now they sound in time, but when played back are out by an amount dependent on overall latency.
Even with small latencies (I can operate at around 2.6 m/s) this can throw the feel of intricate percussion tracks etc. off.
Hope this helps to clarify

[LesC]

Alex,

Please reply and confirm that you understand what is needed here and that it is being fixed very soon.

If this doesnt get fixed soon, then I'm selling my license to someone who doesnt need MIDI functionality.

[Alex]

Hi LesC,

Please reply and confirm that you understand what is needed here and that it is being fixed very soon.

This is not very helpful. I asked several questions in my last statement so it is up to you to decide if I understand what you want.

Beside that we do not talk about a possible bug fix but a change of an intended behavior of Live which is already exist for MIDI since version 4 and for Audio since version 3.

regards,
/Alex

[roby]

Alex, with all due respect, I think what we all want is for everything to be conpensated and accurate. There's really no use or sense to have something delayed when it shouldn't be. I understand that this is the current behavour, but it really isn't the the best or most efficient one. I also understand that it seems that fixing this problem/behaviour probably means re-writing alot of code...if so, this is a difficult position to be in.
But if you put things in perspective, not even an old Atari MIDI sequencing program behaves this way....

LesC, icedsushi,

sorry but I thought I already explained this in the other thread.

Depending on a track's monitoring setting, a recorded clip will be compensated or not. "In" and "Auto" = record without compensation. "Off" = record with compensation. Same for Audio and MIDI. This is the intended behavior and only difference to Live 4 is that there was no "Off" monitoring option for MIDI tracks. So in Live 4 it was not possible at all to compensate MIDI recordings.

Now, suppose I set up 2 MIDI tracks each assigned the same MIDI input. I then ARM both MIDI tracks 1 and 2. I set the monitoring for MIDI track 1 to AUTO (or IN) and I set the monitoring for MIDI track 2 to OFF. Now I Launch an empty scene which triggers the two armed MIDI tracks to begin recording. I play some MIDI which is recorded by both tracks. I then hit the stop buttom. Now I examine the two MIDI clips. The clip on MIDI track 1(monitor set to AUTO or IN) is significantly delayed compared to the clip in track 2(monitor set to OFF).

This is clear so far. But why is the clip in track1 delayed compared to the one in track2? Because the one in track 2 is compensated by the overall latency. Is this understandable so far?

14.0 ms + 12.0 ms + 0.00 ms = 25.9 ms

If I change it to read:

14.0 ms + 12.0 ms + -25.9 ms = 0.00 ms

Then I can record MIDI clips with monitoring set to AUTO or IN without inducing the aforementioned delay in the MIDI clips

This is also clear because the clip in track 2 is still compensated by the overall latency but this value is now adjusted to 0. So it has no effect.

if Ableton can record MIDI accurately when monitoring is set to OFF, then there just isnt any reasonable explanation for why it cant record MIDI accurately when monitoring is set to AUTO or IN.

So what do you want is that also the clip in a track with monitoring set to "In" or "Auto" is compensated?

In the other thread I tried to explain why this is not possible for the audible signal coming out of a armed MIDI track with monitoring set to "In" or "Auto" while the recording is running.
Is this also understandable so far?


But theoretical it would be possible to compensate the recorded clip in an armed monitoring "In" or "Auto" track after! the recording is finished.
This will raise up other problems but theoretical it would be possible.
So is it what you would like to have?


regards,
/Alex

[Alex]

Hi folks,

I had a meeting with some of my teammates about this issue.
We agreed that this a complex issue which makes a hard to get it into words.

I understand that most of you would like to have MIDI clips recorded in tracks with "monitoring set to "In" or "Auto" compensated after finishing the recording.
But I still do not understand exactly why you want to have it compensated although you monitor the signal. So I need to know how your special scenario
looks like.



Therefore I ask everyone who wants to help us by sending me an email with the following content:

Please send me a typical Live set (no samples, just a .als) where you record MIDI and try to explain how you work when doing recordings.
So the goal is that I can understand step by step how do you use Live when making recordings.

As this is a complex issue please try to be as detailed as possible.




thanks for your help
regards,
/Alex

[supster]

what are Cubase, Logic, Pro Tools, and all those guys doing to make it work? ...Are they just shifting it automatically by the audio latency after it's recorded like you say?

If that's what fixes it and makes it a more pleasant, seamless user experience, it seems like that's what needs to be done then.

It doesn't matter what's going on behind the scenes. The change in compensation and shift of the midi notes would be invisible to the end user once the clip is recorded.

sounds to me like this is the key to the whole thing.

whatever solution is done should be transparent. making a quick adjustment after the recording is done would do that
.

[Johnisfaster]

when you record midi and highlight it all and manually drag the first note into place doesn't that fix your midi track? this doesn't seem to be that bad to me although I know alot of people aren't down with that

[icedsushi]

Right church, wrong pew.

If you do that, you might as well go ahead and quantize the rest of the notes it while you're at it. Maybe you played that first note exactly on the beat, but most likely you didn't (because you are human) and now you're dragging all the other notes by the incorrect latency amount if you drag it right onto the beat and you didn't play it that way. The point is you should only be dragging by the latency value.

If you drag it by any other value other than the audio latency you aren't preserving the timing of the original performance. There's no ms graph either, so do we really want to do millisecond to 64 math conversion every time we record a clip? I know I don't. It's all about preserving the groove and leaving the performance untouched.

Johnisfaster, so are you interested in having the midi clip recorded exactly how you played it or not? If so, let's stick together here and come up with a solution.

[icedsushi]

Hi Alex,

But I still do not understand exactly why you want to have it compensated although you monitor the signal. So I need to know how your special scenario
looks like.

I think it's a bit obvious why everyone wants this, but I understand the need to explore all scenarios and state the obvious to prevent unintended consequences. I believe I can speak for 99% of people here when I say this. We want to be able to hear a software instrument while we're recording it. The only way to hear a software instrument while you're playing it is to select IN on it's midi track. Can you tell us what other details you are looking for about our special scenarios? I want to be sure I get you the right information since the issue is complex.

Therefore I ask everyone who wants to help us by sending me an email with the following content:

Please send me a typical Live set (no samples, just a .als) where you record MIDI and try to explain how you work when doing recordings.
So the goal is that I can understand step by step how do you use Live when making recordings.

As this is a complex issue please try to be as detailed as possible.

So yes I will be glad to send you a Live Set, and explain my scenario but there's really nothing that special about it. The .als I send you will just be a VST or AU instrument loaded onto a midi track and clips from that track recorded into both the session and arrangement view with monitoring set to IN.

Seems like a simple scenario to me just recording softsynths like normal with a keyboard onto a midi track. Do you need any other information in order to be more clear? I seriously don't know what else to tell you about the Live Set when I send it.

Like "Nod" said earlier...I am willing to persevere until you guys get the information you need, no matter how redundant I think it may be. It's OK with me if this ends up being a 20 page thread back and forth if that what it takes.

[iain.morland]

I'm a brand new user of Live and having bought it today have just discovered this thread.

If the bug isn't fixed, this is bitterly disappointing for someone like me who is more of a 'traditional' musician - i.e. a pianist by trade who prefers to play softsynths live on a full size keyboard rather than creating notes with a mouse or on a mini keyboard. Human timing - not quantizing - is critical to my music.

There seems to have been a bit of a communication breakdown over this issue between users and developers, which I can't quite understand.

I have never programmed a sequencer and appreciate that it must be complex, but I don't see how the bugfix that's being asked for wouldn't simply provide functionality (audio/midi sync *all* of the time) already found in major sequencers. Without wishing to gang up on Alex, I just don't grasp how this is a 'special scenario'. The timing of a midi synth part ought to be identical when being recorded live (monitored), and when played back.

At the same time, I appreciate that adding more plug-ins to a set requires Live's audio engine to do complicated (pre)delay calculations to keep everything in time. Nonetheless, I don't see why this would necessarily make consistently accurate midi placement *impossible*.

Looking forward to seeing how this discussion develops - hopefully positively for all involved!