Anyone familiar with this issue and found a solution to it? I always had it in Studio One (also 2.x, but there the part borders would not extend so it was less obvious). Even with default Studio One settings this occurs.
When recording in a loop the NoteOn message of the notes at the left locator (usually those played on or within 6 ms of the left locator) are being stretched to the start of the previous bar. It only happens when input quantize is disabled and the recording is not started before, within 60 ms or at the start of the left locator. In the image below I successively record a pass...: ...from the loop start (good) ...before the loop start (good) ...at the end of the loop (bad) ...at the end of the loop with IQ (good) |
I can confirm that this does in fact happen. But in order for me to get this to happen I have to start recording near the end of the loop which is simply something I never do.
The solution is to set up a loop, park the cursor at the start of the loop, set a pre roll or count and then you will always get any notes at the start of the loop recorded at that point and these notes do not get moved back to the previous bar.
Specs i5-2500K 3.5 Ghz-8 Gb RAM-Win 7 64 bit - ATI Radeon HD6900 Series - RME HDSP9632 - Midex 8 Midi interface - Faderport 2/8 - Atom Pad/Atom SQ - HP Laptop Win 10 - Studio 24c interface -iMac 2.5Ghz Core i5 - High Sierra 10.13.6 - Focusrite Clarett 2 Pre & Scarlett 18i20. Studio One V5.5 (Mac and V6.5 Win 10 laptop), Notion 6.8, Ableton Live 11 Suite, LaunchPad Pro
|
Jemusic wroteI can confirm that this does in fact happen. But in order for me to get this to happen I have to start recording near the end of the loop which is simply something I never do.Yes exactly, Thank you. It indeed only happens when punching in after the loop start. I often punch in anywhere on the fly no matter where in the loop I'm residing, especially when overdubbing or layering. So that must be the cause I run in to it quite frequently. Jemusic wroteThe solution is to set up a loop, park the cursor at the start of the loop, set a pre roll or count and then you will always get any notes at the start of the loop recorded at that point and these notes do not get moved back to the previous bar.Yes, that works. But it's a bit slow. |
Yes and I very much also appreciate the way you like to work as well. And if you are wanting to punch in at any point in a loop then you are going to come across this issue for sure.
I tend to think of a loop or a pass as something that always starts at the start and ends at the end of the cycle so that is why I like setting things up to start at the beginning. Or I like to punch in at the start and hear the loop first then play etc.. This is worth fixing for sure though for those like yourself who do like to drop in at any point. We should able to do it.
Specs i5-2500K 3.5 Ghz-8 Gb RAM-Win 7 64 bit - ATI Radeon HD6900 Series - RME HDSP9632 - Midex 8 Midi interface - Faderport 2/8 - Atom Pad/Atom SQ - HP Laptop Win 10 - Studio 24c interface -iMac 2.5Ghz Core i5 - High Sierra 10.13.6 - Focusrite Clarett 2 Pre & Scarlett 18i20. Studio One V5.5 (Mac and V6.5 Win 10 laptop), Notion 6.8, Ableton Live 11 Suite, LaunchPad Pro
|
Jemusic wroteThis is worth fixing for sure though for those like yourself who do like to drop in at any point. We should able to do it.Yes, I hope others running in to this will chime in too because it's has been here too long (Studio One 2 also had it). I'm glad you could confirm it. It's also pretty annoying when recording takes in a loop too. Because the first note of each take is stretched through the previous takes. So cleaning up is necessary each time. |
robertgray3 wrotePotential good news- tech support said they were able to “recreate this MIDI issue in our testing here, and have logged the issue with the Studio One developers.”Thanks! Let's hope this will finally be fixed. |
Still in 4.0.0
Niles sort of mentioned it before but I've also noticed since I've been using Instachord and Cthulhu a lot recently that if you loop record the output of a MIDI processor like Cthulhu it can create this issue even if you start recording at the beginning of the loop locators. It seems in that case it's more about the first note of the next loop iteration landing exactly on bar 1. |
robertgray3 wroteStill in 4.0.0 Good reminder. Worth mentioning. I record mostly the way Jemusic mentioned earlier, with pre roll, but it's often nice to be able to record on the fly, and not have to re adjust event position. Would be nice of this was a 4.1 fix.
S1-6.6, HP Omen 17" i7 10th Gen, 32 GB,512 GB TLC M.2 (SSD),1 TB SSD. Win10 Pro, Audient iD14 MkII, Roland JV90, NI S49 MkII, Atom SQ, FP 8, Roland GR-50 & Octapad. MOTU MIDI Express XT. HR824, Yamaha HS-7, NS-1000M, Yamaha Promix 01, Rane HC-6, etc.
New song "Our Time" https://youtu.be/BqOZ4-0iY1w?si=_uwmgRBv3N4VwJlq Visit my You Tube Channel https://youtube.com/@jamesconraadtucker ... PA5dM01GF7 Latest song releases on Bandcamp - Latest albums on iTunes All works registered copyright ©️ |
@robertgray3, first of all thanks for keeping this alive. I'm glad I'm not the only one thinking these kind of peculiarities are annoying.
robertgray3 wroteNiles sort of mentioned it before but I've also noticed since I've been using Instachord and Cthulhu a lot recently that if you loop record the output of a MIDI processor like Cthulhu it can create this issue even if you start recording at the beginning of the loop locators. It seems in that case it's more about the first note of the next loop iteration landing exactly on bar 1.What I've experienced is that when recording the MIDI output of a VST, the processing buffer size (device block or processing block¹) can be very relevant. A bigger processing buffer can result in sloppier timing. How severe differs from plugin to plugin. But it could be causing that the NoteOn issue is exposed more frequently, because the NoteOn messages aren't exact (sometimes early sometimes late). ¹ Mind that non-monitored instruments in Low Latency Mode for Instrument use a large processing buffer |
Thanks for keeping the dream alive, guys. Been a hassle every single day for 6 years now. I wish bugs like these were prioritized ahead of any new feature (with their own additional bugs), but I guess it's the way of the world. My opinion is that this should have been fixed in the v.2 cycle, before the upgrade to v.3.
Anyone care to remind them of this issue? I'll send support a message now and refer to this topic. The more the better. |
Yeah! 4.1.1
|
Users browsing this forum: josephvickrey and 13 guests