sonarman1
Max Output Level: -85 dBFS
- Total Posts : 255
- Joined: 2016/02/22 11:26:16
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/14 06:28:37
(permalink)
brundlefly
The reply I got was essentially that since a soft synth might be driven by live MIDI input and existing MIDI playback at the same time, it's not possible to apply latency compensation to synth recording
Makes sense. No one has introduced a feature like midi latency compensation coz the soft synth might get live input and playback from existing midi notes as well at the same time. That again proves what I found out and posted. Recording has latency playback doesn't. If compensation has to be created it should be created only for live input and not to the existing midi notes. Is that so impossible? Must be! if its it possible we would have had such a feature now in every daws for years! But to me this still looks pretty simple. This feature can be introduced same as the quantize feature. After recording the midi notes instead of selecting the notes a applying quantize, users can select the notes and apply 'latency compensation' to the notes so that the recorded notes move forward the no of ms required. Should be a great new feature. Hope the bakers implement this.
|
subtlearts
Max Output Level: -53.5 dBFS
- Total Posts : 2200
- Joined: 2006/01/10 05:59:21
- Location: Berlin
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/14 08:31:04
(permalink)
|
Slugbaby
Max Output Level: -33.5 dBFS
- Total Posts : 4172
- Joined: 2004/10/01 13:57:37
- Location: Toronto, Canada
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/14 09:28:20
(permalink)
I have the same problem that I think you have. Whether it's because I play the keys slightly ahead of where I want to, or because of the latency, i've found a simple fix.
I highlight ALL the MIDI data in the track, and simply drag it all later (to where the first note SHOULD strike). Then, the timing issue has been corrected, while the playing is still real and un-quantized.
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 2007/09/14 14:57:59
- Location: Manitou Spgs, Colorado
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/14 12:26:51
(permalink)
sonarman1
brundlefly
The reply I got was essentially that since a soft synth might be driven by live MIDI input and existing MIDI playback at the same time, it's not possible to apply latency compensation to synth recording
Makes sense. No one has introduced a feature like midi latency compensation coz the soft synth might get live input and playback from existing midi notes as well at the same time. That again proves what I found out and posted. Recording has latency playback doesn't. If compensation has to be created it should be created only for live input and not to the existing midi notes. Is that so impossible? Must be! if its it possible we would have had such a feature now in every daws for years! But to me this still looks pretty simple. This feature can be introduced same as the quantize feature. After recording the midi notes instead of selecting the notes a applying quantize, users can select the notes and apply 'latency compensation' to the notes so that the recorded notes move forward the no of ms required. Should be a great new feature. Hope the bakers implement this.
This is not about "MIDI latency" it's about compensation for audio latency. And audio buffering affects playback as well as recording latency. Here's the explanation direct from the proverbial 'horse's mouth', regarding why soft synth recording isn't compensated: We don't latency compensate synth ports. Soft synth inputs are treated differently from hardware inputs.Why are they different? A virtual synth port has audio that can be triggered by sequenced MIDI as well as live MIDI. Sequenced MIDI is cooked ahead of time and is always available exactly at the time that the buffer is processed. Hence there is no need for output latency compensation. In fact if we attempted to compensate the recorded audio it would be out of time (earlier) compared to the sequenced MIDI.Since a synth port can contain audio from live MIDI as well as sequenced MIDI we cant apply a one size fits all approach here. When doing synth recording with live inputs you need to record at the lowest latency possible to avoid the audio delay. I have to admit on re-thinking this that it should still be possible to compensate the latency of soft synth audio from merged sequenced and live MIDI input after the fact by sliding the recorded audio earlier in timeline, as is done with regular audio inputs, so this might need to be revisited. But since it's not possible to avoid monitoring latency of soft synths by direct-monitoring the instrument's output as you can with external audio input, you will necessarily have to be recording with low latency so this really shouldn't be an issue.
SONAR Platinum x64, 2x MOTU 2408/PCIe-424 (24-bit, 48kHz) Win10, I7-6700K @ 4.0GHz, 24GB DDR4, 2TB HDD, 32GB SSD Cache, GeForce GTX 750Ti, 2x 24" 16:10 IPS Monitors
|
sonarman1
Max Output Level: -85 dBFS
- Total Posts : 255
- Joined: 2016/02/22 11:26:16
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/14 13:35:33
(permalink)
@brundlefly Yes wrong terminology used technically its not midi latency. May be audio roundtrip latency is the right word?
We don't latency compensate synth ports. Soft synth inputs are treated differently from hardware inputs.
Why are they different? A virtual synth port has audio that can be triggered by sequenced MIDI as well as live MIDI.
Sequenced MIDI is cooked ahead of time and is always available exactly at the time that the buffer is processed. Hence there is no need for output latency compensation. In fact if we attempted to compensate the recorded audio it would be out of time (earlier) compared to the sequenced MIDI.
That's exactly what I have noticed and I have been telling. Having a compensation in the output of synth port will only mess up things more coz the playback of midi sequences has no latency (as they dont have to go through the roundtrip I guess) Only the live midi input has the latency. This is probably the reason why this compensation had never been implemented.
I have to admit on re-thinking this that it should still be possible to compensate the latency of soft synth audio from merged sequenced and live MIDI input after the fact by sliding the recorded audio earlier in timeline, as is done with regular audio inputs, so this might need to be revisited.
That would be great if the live midi alone can be compensated. But if that's possible why had no one implemented it yet. So I believe may be that's not possible at all.
But since it's not possible to avoid monitoring latency of soft synths by direct-monitoring the instrument's output as you can with external audio input, you will necessarily have to be recording with low latency so this really shouldn't be an issue.
You are right. When that is the case its essential to be recording with low latency. To me that's not really the issue. (Coz we have automatic brain compensation  ) With 30-40milli sec latency or even more! I have no problem at all in playing down the stuffs I need. I guess no one will find that a problem. With a buffer size of 512samples in ASIO i get only 31ms latency. I have never needed to keep the buffer size higher than 750samples. So an average 30-40ms of latency is what the worst latency everyone can get (Unless their system specification is way to bad or they have kept the buffer size or some other setting way to high)(Most users have latencies lower than 10ms). while recording with a 30-40ms latency we don't even notice any delay. Our brain compensates by itself by accurately playing the notes 30-40milli sec ahead. Pretty awesome really  It just happens automatically. This compensation our brain brilliantly does to override the latency goes wasted when the recorded midi is played back without latency. That's where we have the issue now. During playback we gotta override this compensation that our brain came up with. We gotta move the notes bit forward. And that's the fix. Perhaps another way to compensate this is to delay the audio of midi playback as well. But that's doing it all in the wrong way. We just have to move the notes milliseconds forward depending on our round trip latency. To make it even more easy. A new feature can be introduced same as the quantize feature. Just select the notes and 'override the latency'. (If the buffer size or audio driver gets changed the roundtrip latency also gets changed, so this feature should remember the latency with which the midi notes got recorded). If there is such a feature all we have to do is just select and apply. That will be really cool 
post edited by sonarman1 - 2016/04/14 14:14:30
|
sonarman1
Max Output Level: -85 dBFS
- Total Posts : 255
- Joined: 2016/02/22 11:26:16
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/14 13:40:13
(permalink)
Slugbaby
I have the same problem that I think you have. Whether it's because I play the keys slightly ahead of where I want to, or because of the latency, i've found a simple fix.
I highlight ALL the MIDI data in the track, and simply drag it all later (to where the first note SHOULD strike). Then, the timing issue has been corrected, while the playing is still real and un-quantized.
yes thats what I do for now. Also you can note your total roundtrip latency and drag them exactly the no of req millisec to get more accurate fix.
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 2007/09/14 14:57:59
- Location: Manitou Spgs, Colorado
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/14 14:02:33
(permalink)
sonarman1
You are right. When that is the case its essential to be recording with low latency. To me that's not really the issue. (Coz we have automatic brain compensation ) With 40-60milli sec latency or even more! I have no problem at all in playing down the stuffs I need. I guess no one will find that a problem. Coz while recording this we don't even notice an issue. Our brain compensates by itself by accurately playing the notes 40-60milli sec ahead. Pretty awesome really It just happens automatically. This compensation our brain brilliantly does to override the latency goes wasted when the recorded midi is played back without latency. That's where we have the issue now. During playback we gotta override this compensation that our brain came up with. We gotta move the notes bit forward. And that's the fix. Perhaps another way to compensate this is to delay the audio of midi playback as well. But that's doing it all in the wrong way. We just have to move the notes milliseconds forward depending on our round trip latency. To make it even more easy. A new feature can be introduced same as the quantize feature. Just select the notes and 'override the latency'. (If the buffer size changes the roundtrip latency also changes, so this feature should remember the latency with which the midi notes got recorded). Just select and apply. It will be really cool
Most musicians find it unpleasant - if not terribly difficult - to play live with more than about 25-30ms of total latency between the fingers and the audio reaching the ear. At a more typical RTL of 6-12ms (or less) with the input latency being at most half the total, this is really of no consequence. What I keep coming back to is that your original post showed something much worse than this happening with MIDI recording relative to the timeline, quite apart from anything to do with audio latency. That should not be happening, and isn't something that should require any enhancement to the existing latency compensation functionality. I think this thread has gotten off-track by going into audio latency.
SONAR Platinum x64, 2x MOTU 2408/PCIe-424 (24-bit, 48kHz) Win10, I7-6700K @ 4.0GHz, 24GB DDR4, 2TB HDD, 32GB SSD Cache, GeForce GTX 750Ti, 2x 24" 16:10 IPS Monitors
|
sonarman1
Max Output Level: -85 dBFS
- Total Posts : 255
- Joined: 2016/02/22 11:26:16
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/14 14:18:31
(permalink)
Most musicians find it unpleasant - if not terribly difficult - to play live with more than about 25-30ms of total latency between the fingers and the audio reaching the ear. At a more typical RTL of 6-12ms (or less) with the input latency being at most half the total, this is really of no consequence.
Yes lesser than 12ms latency is Ideal
What I keep coming back to is that your original post showed something much worse than this happening with MIDI recording relative to the timeline, quite apart from anything to do with audio latency. That should not be happening, and isn't something that should require any enhancement to the existing latency compensation functionality.
I think this thread has gotten off-track by going into audio latency.
Let me check. Can someone tell me 1ms=?ticks. Or 1tick= ?ms. Might be useful.
|
sonarman1
Max Output Level: -85 dBFS
- Total Posts : 255
- Joined: 2016/02/22 11:26:16
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/14 14:39:24
(permalink)
At 120BPM. When tick per quarter note is set at 960. quarter note = 960ticks = 500msec 8th note = 480ticks = 250msec 16th note = 240 ticks = 125msec Hope I am right. Will get back tomorrow. Also will try the IgnoreMIDIInTimeStamps=1 in TTSSEQ.INI
post edited by sonarman1 - 2016/04/15 04:34:14
|
Sanderxpander
Max Output Level: -36.5 dBFS
- Total Posts : 3873
- Joined: 2013/09/30 10:08:24
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/14 17:58:02
(permalink)
I have trouble with anything over 10ms latency. I can play but it feels sluggish. At 25ms or more it would so seriously affect my performance that I wouldn't feel content with whatever I laid down, because there would be no idea of timing during playing. I agree with Brundlefly that your initial picture points to a bigger technical problem. You never really answered the original questions (I think?), what hardware are you using and with which drivers?
|
sonarman1
Max Output Level: -85 dBFS
- Total Posts : 255
- Joined: 2016/02/22 11:26:16
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/15 13:50:40
(permalink)
Unable to find any time to get deep into this. For now I tried to edit TTSSEQ.INI only to find out that there is no 'IgnoreMIDIInTimeStamps= ' in it or any anything close to it. I juggle between two computers in both my houses. Both run Win10 64bit. Intel Core i3-4150 Haswell 3.5 GHz. One is pretty old with Intel core2duo 2.80GHz. Mostly recorded using Maudio keystation. To make sure the midi controller is not the issue behind this I even tried recording using Sonar's Virtual controller. Used both mouse and the computer keyboard to input notes. The latency is just the same as how it is while using midi controller. So this is not related to the controller. I am sure of that now. I don't even think there is any additional issue here. As a matter of fact I have recorded for years and what I have observed is that although the notes may go till 240ticks ahead sometimes, they are just about a 120 ticks ahead(on average). Only few notes may go till 240 ticks. 120 ticks ahead is what I get normally. Not 240 ticks ahead as it is in my first screen shot. I am not sure why it is so in my first screen shot. May be while playing to a metronome and repeatedly hitting the note I might have played all the notes bit early. That is also possible or there was some other issue. Not sure though. But usually I only get only abt 120ticks ahead, so I guess we can ignore the first screen shot for now. I recorded a few notes now please go by these ones. Both of these I rec 2 days back while making that lengthy post with synth audio screen shots. This is the one I recorded with 100ms latency 100ms (Do notice here I have recorded some notes continuously at 240ticks ahead. So may be I am prone to making this mistake while repeatedly playing the notes.)  (open the image in new tab to see it clearly) 10ms  This one I rec now today with 31ms latency 31ms Just hitting the same note repeated might not be a good way to test this. I might be continuously hitting bit earlier or later. so I recorded a melody to see how it comes. 31ms latency here as well. melody31ms continuation  May be some more analysis is need. No time for now. Will get back 2morrow. Do interpret these. Here in the 10ms screenshot I am not sure why I got that much ticks ahead while playing with latency of 10ms. May be I am such a bad player who has the habit of playing everything bit ahead. Anyway thanks once again for all the help till now.
post edited by sonarman1 - 2016/04/16 05:29:13
|
sonarman1
Max Output Level: -85 dBFS
- Total Posts : 255
- Joined: 2016/02/22 11:26:16
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/16 07:48:38
(permalink)
|
sonarman1
Max Output Level: -85 dBFS
- Total Posts : 255
- Joined: 2016/02/22 11:26:16
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/16 08:00:58
(permalink)
If needed I can also move all these notes 31ms forward and post the screen shots.
|
sonarman1
Max Output Level: -85 dBFS
- Total Posts : 255
- Joined: 2016/02/22 11:26:16
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/17 06:25:58
(permalink)
Recorded with a external synth. First time rec a ext synth in home. Gave a line input via pc's inbuilt sound card . Hope that's not a problem. Is the external synth audio supposed to be latency free? I do notice latency while playing and recording. Which seems to be bit more than the soft synth latency. I trigger the ext synth track and soft synth track simultaneously and I get dual sounds. With soft synth audio followed by ext synth audio. So the ext synth track sounds more delayed than the soft synth track during playback. But the recorded audio of ext synth is not much delayed (it gets compensated?). Not much delayed from the midi note but delayed little bit. All the ext synth audio is 15-17ms delayed than the midi note. Whether recorded while live input or later from the rec midi the ext synth audio is always 15-17ms delayed. Irrespective of the round trip latency. I recorded with 40ms, 60ms, 100ms, always its delayed only 15-17ms. But while playing I can hear that the latency is more, its about a 20% more than the latency while recording softsynth. If its compensated then its okay but why there is still a 15-17ms latency btw midi and audio? Any possible reasons? Meanwhile all the notes are ahead of the grid lines just like the midi notes. Tired of posting screen shots. While recording soft synth the delay between midi and audio was similar to the roundtrip latency. In 31ms the diff was 31ms. In 60ms then the delay was 60ms. But in ext synth its always 15-17ms irrespective of the audio latency ms. It might be possible like @brundlefly's opinion I might be having some other technical issue. Rec audio shows 15-17ms delay but the delay I hear while playing is surely much more than that. Like that I guess maybe while rec soft synth aswell although the delay showed btw the audio and midi is same as the roundtrip latency the delay I hear while playing might be even more than that. Never ending confusions. 
post edited by sonarman1 - 2016/04/17 06:47:05
|
Sanderxpander
Max Output Level: -36.5 dBFS
- Total Posts : 3873
- Joined: 2013/09/30 10:08:24
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/17 12:20:29
(permalink)
You don't have a dedicated audio interface at all? The KeyStation is just a midi/USB keyboard, right? If so, I suspect this lies at the source of your problem.
|
chuckebaby
Max Output Level: 0 dBFS
- Total Posts : 13146
- Joined: 2011/01/04 14:55:28
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/17 14:37:15
(permalink)
im not sure if you've already listed your specs (interface, system, exc) but it does help if you put it in to your Sig, this way any post you have people have an idea of what you are running. what kind of situation you are surrounded by.
a lot of guess work goes in to trouble shooting but this can be 99% eliminated by upfront telling everyone your set up.
I thought you had an audio card (an interface) thus my first reply would have been to you:
are you using asio and try lowering your buffer size on your AI
Windows 8.1 X64 Sonar Platinum x64 Custom built: Asrock z97 1150 - Intel I7 4790k - 16GB corsair DDR3 1600 - PNY SSD 220GBFocusrite Saffire 18I8 - Mackie Control
|
sonarman1
Max Output Level: -85 dBFS
- Total Posts : 255
- Joined: 2016/02/22 11:26:16
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/04/21 01:25:39
(permalink)
True that. Ideal thing is to get a dedicated audio interface first. Which I am about to, but its gonna take some time. Till then I will continue moving the notes toward the grid.
|
sonarman1
Max Output Level: -85 dBFS
- Total Posts : 255
- Joined: 2016/02/22 11:26:16
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/05/17 03:25:23
(permalink)
Thanks for your reply in other thread. http://forum.cakewalk.com...730028-p2.aspx#3417021
As mentioned in your previous thread about this, Soft synth recording is not compensated for latency like normal audio input, so it's not a good timing reference (http://forum.cakewalk.com/FindPost/3400689). Also, since your timeline doesn't show M:B:T, it's not really possible to know what's early/late and by how much compared to the audio metronome.
Well I posted other screen shots that showed M:B:T in the PRV. The notes are always ahead. I dont suppose now it will be necessary. If necessary I can post those same shots with M:B:T.
I see there was a follow-up post in your earlier thread that I missed about recording simultaneous MIDI and audio from a keyboard synth. You mentioned getting a fixed audio latency regardless of ASIO buffer size. That is typical if you're driving the synth by MIDI echoed through SONAR because of keyboard scan time plus MIDI round-trip time, synth response time and D/A conversion in the synth if you're recording an analog output. 15-17ms isn't out of line if your MIDI interface is on the slow side. You'll get less un-compensated latency if you set the keyboard synth to use Local Control.
I kind of get it but i don't understand this "You'll get less un-compensated latency if you set the keyboard synth to use Local Control." You mean to say if I just record the audio out alone from the ext synth I will get low latency than now during playback? I will try.
You may also have some uncompensated interface latency if the driver isn't accurately reporting latency to SONAR. SONAR has a Manual Offset to add compensation for this 'hidden' latency. You can use a tool like the CEntrance Latency Tester to measure the actual latency and enter the difference between that actual value and the reported round-trip value in SONAR as the Manual Offset in samples.
I see. Possible. I dont record audio at all in my setup. Even if I had to I would be using a friends place or a studio. So I am not gonna care much abt this. But still I will test sometime soon for any hidden latency. And update the same here.
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 2007/09/14 14:57:59
- Location: Manitou Spgs, Colorado
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/05/17 10:32:38
(permalink)
sonarman1
I kind of get it but i don't understand this "You'll get less un-compensated latency if you set the keyboard synth to use Local Control." You mean to say if I just record the audio out alone from the ext synth I will get low latency than now during playback?
I meant with regard to your post #44, that if you record simultaneous audio and MIDI from a keyboard synth, you should use Local Control to have MIDI drive the synth directly rather than echoing it through SONAR. If the external synth is a separate module from your keyboard (not clear form the post), you'll have to route MIDI to the synth module, and then from its THRU into SONAR to eliminate as much of the MIDI latency from the synth response as possible. But if you're using an onboard soundcard with WDM drivers as clock reference, all bets are off in terms of dialing in latency compensation and getting solid MIDI timing. If your budget is forcing you to shop at the bottom end of the market for new equipment, I recommend you look for a good used ASIO interface. Other than monitors and headphones, I haven't bought an un-used piece of MIDI or audio gear since 1988, and I've had very good luck with used stuff. Even my PC is a refurb. I have resources, but I'm a cheapskate
SONAR Platinum x64, 2x MOTU 2408/PCIe-424 (24-bit, 48kHz) Win10, I7-6700K @ 4.0GHz, 24GB DDR4, 2TB HDD, 32GB SSD Cache, GeForce GTX 750Ti, 2x 24" 16:10 IPS Monitors
|
soens
Max Output Level: -23.5 dBFS
- Total Posts : 5154
- Joined: 2005/09/16 03:19:55
- Location: Location: Location
- Status: offline
Re: Natural Human playing in the PRV grid.
2016/05/17 15:26:32
(permalink)
Whew! After recording a live performance I would just select everything and drag the 1st note to the -0- mark (if it's not already there) so it's right on the beat, and everything else will follow as it was played.
|