I just downloaded the new beta 5.0.3b4 to see if the problem described in this thread: http://www.ableton.com/forum/viewtopic.php?t=26856 had been corrected.
It is not.
I have been totally stupified by this problem since discovering it and reading about it on the forum. I just cant understand why this hasn't been fixed. Its very upsetting to pay this kind of money for something I cant use as I intended.
Hopefully I'm missing something. Please clue me in if so.
Thanks,
Les
Midi record timing still not right in 5.0.3b4
Hi LesC,
the change log said the the MIDI input time accuracy is improved. That again means that the timing information provided by the MIDI driver is processed from Live which again improves the timing accuracy.
So this should reduce the jitter of incoming MIDI events relative to each other.
We did not change anything directly related to the routing or the how the compensation works.
So this is not directly related to the various issues of the above thread: http://www.ableton.com/forum/viewtopic.php?t=26856
A bug I can confirm is that the MIDI latency compensation is based on the same values as the Audio compensation, meaning it uses the audio input latency too, which is simply wrong. But this is a fixed value.
As far as I understand the most problem is that incoming MIDI events are sometimes early, sometimes late so more or less randomly.
This should be improved with the Live 5.0.3b4 but still depends a lot on the timing information provided from the MIDI driver which again is much better on OS X.
Under Windows we are near at the end of what is possible concerning MIDI accuracy using MME for MIDI. We hope that providing support for DirectMusic will improve the MIDI timing accuracy in a future version of Live.
So finally my question concerning MIDI input timing, does it feel better with Live 5.0.3b4 or is the the same like in Live 5.0.2?
regards,
/Alex
the change log said the the MIDI input time accuracy is improved. That again means that the timing information provided by the MIDI driver is processed from Live which again improves the timing accuracy.
So this should reduce the jitter of incoming MIDI events relative to each other.
We did not change anything directly related to the routing or the how the compensation works.
So this is not directly related to the various issues of the above thread: http://www.ableton.com/forum/viewtopic.php?t=26856
A bug I can confirm is that the MIDI latency compensation is based on the same values as the Audio compensation, meaning it uses the audio input latency too, which is simply wrong. But this is a fixed value.
As far as I understand the most problem is that incoming MIDI events are sometimes early, sometimes late so more or less randomly.
This should be improved with the Live 5.0.3b4 but still depends a lot on the timing information provided from the MIDI driver which again is much better on OS X.
Under Windows we are near at the end of what is possible concerning MIDI accuracy using MME for MIDI. We hope that providing support for DirectMusic will improve the MIDI timing accuracy in a future version of Live.
So finally my question concerning MIDI input timing, does it feel better with Live 5.0.3b4 or is the the same like in Live 5.0.2?
regards,
/Alex
Alex,
The bug that you just confirmed is exactly the bug he is referring to in that thread. You also confirmed the bug to us in the thread if you read back on page 3. We have all been waiting patiently but just want to know the plans here since it is a pretty serious bug that affects basic functionality. Can you confirm that the bug with audio latency being added to the midi latency will be fixed in the 5.0.3 final release?
You acknowlege the bug is a wrong fixed value latency but then go on to say that the timing is random, sometimes late sometimes early, which is somewhat contradictory. Just making sure you understand the problem clearly.
The recorded midi input timing is both consisitently and measureably wrong. It is directly dependant upon the overall latency setting and the use of plugins which can add to the compensation value while monitoring is set to AUTO or IN.
Cedric
The bug that you just confirmed is exactly the bug he is referring to in that thread. You also confirmed the bug to us in the thread if you read back on page 3. We have all been waiting patiently but just want to know the plans here since it is a pretty serious bug that affects basic functionality. Can you confirm that the bug with audio latency being added to the midi latency will be fixed in the 5.0.3 final release?
You acknowlege the bug is a wrong fixed value latency but then go on to say that the timing is random, sometimes late sometimes early, which is somewhat contradictory. Just making sure you understand the problem clearly.
The recorded midi input timing is both consisitently and measureably wrong. It is directly dependant upon the overall latency setting and the use of plugins which can add to the compensation value while monitoring is set to AUTO or IN.
Cedric
Last edited by icedsushi on Wed Dec 07, 2005 8:09 pm, edited 1 time in total.
Hi icedsushi,
Maybe we are able (at least) to remove the adding of the audio in latency without any user interface change. This would be just a half fix but maybe better than nothing.
regards,
/Alex
I'm not this sure because there are several partly contradicting issues discussed in this other thread.The bug that you just confirmed is exactly the bug he is talking about in that thread.
Unfortunately I cannot say it. The code is very generic there and it is very risky to change it. Furthermore to make it really right you would not an own compensation value for MIDI only or more worse you would need an compensation value for each MIDI input device. This makes such a change really big.Can you confirm that the bug with audio latency being added to the midi latency will be fixed in the 5.0.3 final release?
Maybe we are able (at least) to remove the adding of the audio in latency without any user interface change. This would be just a half fix but maybe better than nothing.
regards,
/Alex
Alex,
The "half fix" would be very much welcomed and be a HUGE improvement.
I understand these issues are complicated...
Since this bug throws the timing off playing softsynths for every user on a day to day basis, don't you think it would be good to move it up a notch on the to-do list from a "maybe" to "one of our top priorities"? We are all doing workarounds and I'm sure many people are not aware how their input record timing is being negatively affected.
Cedric
The "half fix" would be very much welcomed and be a HUGE improvement.
I understand these issues are complicated...Since this bug throws the timing off playing softsynths for every user on a day to day basis, don't you think it would be good to move it up a notch on the to-do list from a "maybe" to "one of our top priorities"? We are all doing workarounds and I'm sure many people are not aware how their input record timing is being negatively affected.
Cedric
Cedric,
you could make the following test fro me:
Instead you your normal compensation value (in den Audio preferences) you can setup a compensation value lowered by the audio input latency.
This would simulate how it feels if we would like to change this behavior.
So the question is: Is the accuracy then ok?
regards,
/Alex
you could make the following test fro me:
Instead you your normal compensation value (in den Audio preferences) you can setup a compensation value lowered by the audio input latency.
This would simulate how it feels if we would like to change this behavior.
So the question is: Is the accuracy then ok?
regards,
/Alex
I believe we touched on that before in another thread a few months ago Alex but I can't find the thread.
I'm tempted to say yes but I will try it some more tonight when I'm back at my Mac and report back. I'm hoping others can participate too.
I'm not trying to be smart, but how about you Alex...you Abe guys are the experts. Where do you prefer it to get the timing right?
I'm tempted to say yes but I will try it some more tonight when I'm back at my Mac and report back. I'm hoping others can participate too.
I'm not trying to be smart, but how about you Alex...you Abe guys are the experts. Where do you prefer it to get the timing right?
OK
Not sure why its so hard to understand the problem and get it fixed. But I do have a bit of new (i think) information for Ableton and those experiencing this problem.
First, let me say I'm using ASIO drivers on an Aardvark Q10 just in case there's a difference between using Direct X and ASIO.
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).
Thats a re-explanation of the problem we've seen discussed over and over again on this forum. I include that here for the sake of clarity. Hopefully its clear
Alex, does that make sense to you? Please let me know if it does not. Obviously, we cant get this issue fixed if Ableton doesnt understand what it is.
Now, today in my efforts to find a solution, I happened upon a way to half-solve this problem. If I enter a negative number into the Overall Latency box in the Audio Prefs such that the total overall latency is reported as zero, then recording MIDI clips with monitoring set to IN or AUTO no longer causes the resultant notes in the clip to be delayed.
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.
Perhaps I could use the negative value when recording MIDI then set it back to zero when I'm not recording MIDI. Somehow I think that may cause other problems. Perhaps I will experiment with that.
At any rate, 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 please Ableton, provide an explanation followed by a fix ASAP. This bug just plain stinks.
Not sure why its so hard to understand the problem and get it fixed. But I do have a bit of new (i think) information for Ableton and those experiencing this problem.
First, let me say I'm using ASIO drivers on an Aardvark Q10 just in case there's a difference between using Direct X and ASIO.
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).
Thats a re-explanation of the problem we've seen discussed over and over again on this forum. I include that here for the sake of clarity. Hopefully its clear
Alex, does that make sense to you? Please let me know if it does not. Obviously, we cant get this issue fixed if Ableton doesnt understand what it is.
Now, today in my efforts to find a solution, I happened upon a way to half-solve this problem. If I enter a negative number into the Overall Latency box in the Audio Prefs such that the total overall latency is reported as zero, then recording MIDI clips with monitoring set to IN or AUTO no longer causes the resultant notes in the clip to be delayed.
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.
Perhaps I could use the negative value when recording MIDI then set it back to zero when I'm not recording MIDI. Somehow I think that may cause other problems. Perhaps I will experiment with that.
At any rate, 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 please Ableton, provide an explanation followed by a fix ASAP. This bug just plain stinks.
Les
EXXXACTLY!!!
thank you
thank you
thank you so much, seriously
...for putting into words so succinctly what I have been trying to say over and over for months, explaining to other forum members, troubleshooting and whatnot. You are very clear, concise, and logical in your post which you do better than me I must say.
I can't possibly see how there is anything left to question or how it can be misinterpereted now. Now I assume we can finally move to the next step, past describing the problem repeatedly, no?
I hope that Ableton understands too. That's the most important here. Alex, can we get this bug fixed in 5.03 PLEASE?! I thought you guys already knew the exact details of the bug back in September.
It's not random at all. Alex, like LesC says, the amount of midi recording error is directly proportional to the audio latency.
thank you
thank you
thank you so much, seriously
...for putting into words so succinctly what I have been trying to say over and over for months, explaining to other forum members, troubleshooting and whatnot. You are very clear, concise, and logical in your post which you do better than me I must say.
I can't possibly see how there is anything left to question or how it can be misinterpereted now. Now I assume we can finally move to the next step, past describing the problem repeatedly, no?
I hope that Ableton understands too. That's the most important here. Alex, can we get this bug fixed in 5.03 PLEASE?! I thought you guys already knew the exact details of the bug back in September.
It's not random at all. Alex, like LesC says, the amount of midi recording error is directly proportional to the audio latency.
From http://www.ableton.com/forum/viewtopic. ... c&start=30
Sept 27 2005
Where it appears that rewire tracks are also double delayed when midi tracks in live are controlling reason devices etc., as though they were an external audio signal, with a delay for the input & the output, so pdc apparently only 'half' works for them - or something of that nature.
Just wondering as they seem to be somewhat related issues - concerning 'fixed' latency values & PDC etc.
For someone who is using reason rewired together with vsti's & maybe some warped audio tracks this is something of a nightmare - as workarounds are piled on top of workarounds in order to achieve tight timing - with a complex track this can become very confusing - bouncing down & having to move audio a few m/s this way & that way in order to keep the groove.
It is obviously 'fixable' as I personally have never had a problem of this nature with any other host supporting rewire, vsti's & PDC.
Sept 27 2005
Pretty much reiterating what was said above, now I wonder - is this bug/feature in any way related to: http://www.ableton.com/forum/viewtopic.php?t=30254diverdee wrote:ok so played around a bit more, set up two tracks 2 record at the same time - one with monitoring set to either in or auto & the other to none.
The latency settings in audio preferences were 13+13 = 26, so I added a negative value of -26 & the two sets of midi notes line up perfectly now.
Is this what needs to be done each time midi is recorded in order for it to be perfectly in time, or can it be safely left like this & what other effects could this possibly have, re: audio midi sync problems or anything of that nature?
Where it appears that rewire tracks are also double delayed when midi tracks in live are controlling reason devices etc., as though they were an external audio signal, with a delay for the input & the output, so pdc apparently only 'half' works for them - or something of that nature.
Just wondering as they seem to be somewhat related issues - concerning 'fixed' latency values & PDC etc.
For someone who is using reason rewired together with vsti's & maybe some warped audio tracks this is something of a nightmare - as workarounds are piled on top of workarounds in order to achieve tight timing - with a complex track this can become very confusing - bouncing down & having to move audio a few m/s this way & that way in order to keep the groove.
It is obviously 'fixable' as I personally have never had a problem of this nature with any other host supporting rewire, vsti's & PDC.
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.
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
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.
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?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 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.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
So what do you want is that also the clip in a track with monitoring set to "In" or "Auto" is compensated?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.
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
-
bensuthers
- Posts: 760
- Joined: Wed Oct 01, 2003 4:51 am
Alex,
Yep...again, like we said in the other thread, that's what we want.
I can't conceive of a possible reason why anyone wouldn't want the compensation after it's recorded. Especially since you can't select all the midi notes and drag them to the left accurately by the audio latency (in ms) to fix the clip yourself.
Ok, yeah I understand in the other thread theoretically why the compensation can't happen during the recording. You can't move the notes earlier in time before you played them while you're playing them, blah blah blah....But what are Cubase, Logic, Pro Tools, and all those guys doing to make it work? I'm sure this has been done before time and time again. 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 to us that it's not compensated during recording with track monitoring on. Because if you are playing along to what you hear, you are perfectly in time. 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.
Also if you automatically compensate after the recording, it will make Live the ultimate live midi looping tool which this issue is basically the only obstacle. The midi clips could play back instantly on the same track exactly how you played them in. You could monitor playing a soft synth for example, fire the new clip and it would be in time just how you played it.
So short answer in summary: Yeah do it!
Yep...again, like we said in the other thread, that's what we want.
I can't conceive of a possible reason why anyone wouldn't want the compensation after it's recorded. Especially since you can't select all the midi notes and drag them to the left accurately by the audio latency (in ms) to fix the clip yourself.
Ok, yeah I understand in the other thread theoretically why the compensation can't happen during the recording. You can't move the notes earlier in time before you played them while you're playing them, blah blah blah....But what are Cubase, Logic, Pro Tools, and all those guys doing to make it work? I'm sure this has been done before time and time again. 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 to us that it's not compensated during recording with track monitoring on. Because if you are playing along to what you hear, you are perfectly in time. 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.
Also if you automatically compensate after the recording, it will make Live the ultimate live midi looping tool which this issue is basically the only obstacle. The midi clips could play back instantly on the same track exactly how you played them in. You could monitor playing a soft synth for example, fire the new clip and it would be in time just how you played it.
So short answer in summary: Yeah do it!
I also gather (kind of) the theoretical explanation given - but as icedsushi explained also - how come every other application doing this manages to do it seamlessly & tight?
If it's not possible how do they do it?
Also (as mainly musicians) the mechanics of it why/how may be beyond many - what we/they are interested in is software that does what it says on the tin i.e. allows one to play vsti's & record the output (in time, nit shifted back/forward in time) & monitor what we are doing whilst we are doing it.
Asking too much?
Not trying to be obstroperous, but I truly cannot understand why people at ableton HQ can't seem to grasp why/how this is so important for people who are trying to use vsti's in Live - it is critical & lies at the heart of the accusations/feelings many have had for a long time that Live is 'not tight enough' for studio work - because it quite simply isn't whilst the timing of midi is treat this way.
Yep - we want the midi notes placed in the correct place - so that when we play a piece we have recorded back it actually sounds identical (with the same timing) as when we played it - is that so hard to understand? is that too much too ask? is that not what sequencers are for? or can we only do this if we aren't monitoring it? so we can play it & have the timing correct - but only if we can't monitor what we are playing - what kind of surreal catch 22 is that?
If it's not possible how do they do it?
Also (as mainly musicians) the mechanics of it why/how may be beyond many - what we/they are interested in is software that does what it says on the tin i.e. allows one to play vsti's & record the output (in time, nit shifted back/forward in time) & monitor what we are doing whilst we are doing it.
Asking too much?
Not trying to be obstroperous, but I truly cannot understand why people at ableton HQ can't seem to grasp why/how this is so important for people who are trying to use vsti's in Live - it is critical & lies at the heart of the accusations/feelings many have had for a long time that Live is 'not tight enough' for studio work - because it quite simply isn't whilst the timing of midi is treat this way.
Yep - we want the midi notes placed in the correct place - so that when we play a piece we have recorded back it actually sounds identical (with the same timing) as when we played it - is that so hard to understand? is that too much too ask? is that not what sequencers are for? or can we only do this if we aren't monitoring it? so we can play it & have the timing correct - but only if we can't monitor what we are playing - what kind of surreal catch 22 is that?