17 posts
Page 1 of 1
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)

Image

OS: Windows 7 Pro x64 | HW: P9X79 • i7 3930K • 16GB • HD6450 (WQHD) • RME AIO
User avatar
by Jemusic on Thu Jun 22, 2017 3:11 pm
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 PCI HDSP9632 - Steinberg Midex 8 Midi interface - Faderport 8- Studio One V4
iMac 2.5Ghz Core i5 - Sierra 10.12.6 - Focusrite Clarett thunderbolt interface and Scarlett 18i20

Poor minds talk about people, average minds talk about events, great minds talk about ideas - Eleanor Roosevelt

https://soundcloud.com/jeff-evans
User avatar
by niles on Fri Jun 23, 2017 5:23 am
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. ;)

OS: Windows 7 Pro x64 | HW: P9X79 • i7 3930K • 16GB • HD6450 (WQHD) • RME AIO
User avatar
by Jemusic on Fri Jun 23, 2017 4:27 pm
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 PCI HDSP9632 - Steinberg Midex 8 Midi interface - Faderport 8- Studio One V4
iMac 2.5Ghz Core i5 - Sierra 10.12.6 - Focusrite Clarett thunderbolt interface and Scarlett 18i20

Poor minds talk about people, average minds talk about events, great minds talk about ideas - Eleanor Roosevelt

https://soundcloud.com/jeff-evans
User avatar
by niles on Sat Jun 24, 2017 5:33 am
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.

Image

OS: Windows 7 Pro x64 | HW: P9X79 • i7 3930K • 16GB • HD6450 (WQHD) • RME AIO
User avatar
by niles on Fri Sep 29, 2017 1:54 am
Still standing for 3.5.2

OS: Windows 7 Pro x64 | HW: P9X79 • i7 3930K • 16GB • HD6450 (WQHD) • RME AIO
User avatar
by shanabit on Thu Nov 30, 2017 10:45 am
Same error here

S1 Pro 3.5.6, Cubase 9.5.30
MR816X, OSX High Sierra 10.13.6
2010 MacPro Dual 2.4 quad,14 GB Ram
User avatar
by robertgray3 on Thu Feb 22, 2018 8:46 am
Still a bug in 3.5.5

I'll open a support ticket and remind them ;)

Mac OS X High Sierra 10.13.6
MacBook Pro 15" Mid-2014
User avatar
by robertgray3 on Thu Feb 22, 2018 11:15 am
Potential 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.”

Mac OS X High Sierra 10.13.6
MacBook Pro 15" Mid-2014
User avatar
by niles on Thu Feb 22, 2018 1:44 pm
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! :thumbup:
Let's hope this will finally be fixed.

OS: Windows 7 Pro x64 | HW: P9X79 • i7 3930K • 16GB • HD6450 (WQHD) • RME AIO
User avatar
by robertgray3 on Mon Apr 16, 2018 10:20 am
Still here in 3.5.6

Anyone found a faster way to clean these notes up aside from deleting it and redrawing it manually? Especially when loop recording.

Mac OS X High Sierra 10.13.6
MacBook Pro 15" Mid-2014
User avatar
by robertgray3 on Thu May 24, 2018 4:54 pm
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.

Mac OS X High Sierra 10.13.6
MacBook Pro 15" Mid-2014
User avatar
by Lokeyfly on Fri May 25, 2018 1:59 am
robertgray3 wroteStill 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.


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.

PC Sony VAIO laptop, Intel i7, 64-bit, 8 gig ram, S1 Pro, v3.2
User avatar
by niles on Fri May 25, 2018 2:36 am
@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

OS: Windows 7 Pro x64 | HW: P9X79 • i7 3930K • 16GB • HD6450 (WQHD) • RME AIO
User avatar
by robertgray3 on Wed Jul 11, 2018 6:30 pm
Still an issue in version 4.0.1, pretty prohibitive when recording instruments' output while looping with the intent to manipulate it later.

Mac OS X High Sierra 10.13.6
MacBook Pro 15" Mid-2014
User avatar
by niles on Fri Jul 20, 2018 5:39 am
Yes, issue remains as it is.

Image

OS: Windows 7 Pro x64 | HW: P9X79 • i7 3930K • 16GB • HD6450 (WQHD) • RME AIO
User avatar
by Skaperverket on Fri Oct 05, 2018 3:41 am
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.

Self-built PC (Asus WS X299 Pro, Intel Core i9 7940X [14/28 cores @4.7GHz], 64 GB RAM, 2 × 500 GB 850 Evo SSD, 1 × 1 TB SM961 NVMe, Gigabyte GTX 1050 2G), Windows 10 1607, S1 3.5.4, RME HDSPe RayDAT (PCIe).

MacBook Pro (15" Mid 2014: Intel Core i7 4870HQ, 16 GB RAM, 500 GB SSD), OS X 10.11.6, S1 3.5.4,
Lynx Hilo (USB).

17 posts
Page 1 of 1

Who is online

Users browsing this forum: No registered users and 12 guests