SOLVED: FOCUSRITE BUG - Record arm buttons are slow to respond

I mentioned that problem cropping up for me yesterday and today on a another thread.  X1C here.

There is a lag in response on the arm button related to latency. Is this something above and beyond that?

Yeah, five seconds doesn't sound right.

I remember having a similar problem waaaaaaaay back on Pro Audio 6 or 7, running it on a seriously underpowered computer. There was some kind of pre-record buffering process, that in the right (wrong) circumstances could take forever. I wouldn't be surprised to discover that the program still has a similar architecture.

Have you caled tech suport about it? Sounds like a rogue setting somewhere to me.

CakeAlexS


NOTE THIS IS JUST ABOUT RECORD ARM BUTTONS WHEN THE TRANSPORT ISN'T PLAYING. I've set it so record arm buttons do not function during playback (i.e. trying to avoid any driver issues here).
 

Try to enable arming during playback. You may get surprised! In my setup  (RME Fireface 800, 44,1 kHz, buffer 64) arming is 10x faster during playback than stopped. 
Your results may vary...

Yes, I also have this problem... also, trying to scroll in track view, the system is very sluggish.. if I get too far ahead of X1 with my movements, I will get a SONAR NOT RESPONDING freeze and have to reboot.

This is really a buzz kill for creativity, especially for tracking live with a one man show.  I am running X1b, WIN 7, in x64.  My system is a multi thread quad core with 8GB of ram.

Don't know if this makes a difference but I am running two UAD2 cards and my audio is USB (octa capture).

Thought it was something on my end but with many others having the same issue(s), this could be an official performance bug.

Jim

Have you noticed that the OP and Yorolpal are using an audio interface by the same company. I think this Record Arm issue is related to the driver of the audio interface.

I had this issue with my M-Audio 1010LT when SONAR 8 was released. I was using a new beta driver, as I was on the Beta testing team for M-Audio, and I reported the issue to Cakewalk, and they released an update soon to SONAR 8 which fixed the issue.

I reckon that since I was using a new beta driver that Cakewalk didn't have to test, I was experiencing this Record Arm issue. When I reported the issue to Cakewalk, they asked me what driver I was using and I had to tell them about the new beta driver. I reckon after that, they tested with that driver, saw the issue, and fixed it, and I got the fix with the SONAR 8 update.

So, it's good to report such problems to Cakewalk and tell them which driver and audio interface that is being used, so it can help them get to the bottom of the problem. There are also other drivers audio interfaces combinations that have been reported to be a victim of this Record Arm issue, as reported by Jim Roseberry and others, in the past.

Goodluck in getting the issue resolved.

I've not got your specific bug, but as I said, I do see a latency based delay on audio tracks.

Dunno if this is any use, but here's what I'm getting:

• Instantaneous change on MIDI tracks.
• Slight delay on Audio tracks.
• Same behaviour whether "Allow changes during playback" is enabled or not.

Makes no difference on mine whether "Allow changes during playback" is enabled/disabled.

In the Console View I can get a 3 or 4 sec delay if I select multiple tracks and then Control Click to arm/disarm the tracks.  Doing the same in Track View there is no delay.

Dan

Yup, well don't get me wrong, so far this is the only performance issue I've had (not a showstopper but should be fixed, us studio types like things snappy). Then again I only really done a few overdubs in this software, I haven't done a band yet.... I'm making sure I learn this software inside out first.

I'm fairly convinced there's something going odd with the performance of arm buttons and I/O, Dan (thanks for feekback Dan) gets this in console view for instance. I get it a lot worse in console view (but also track view). I guess Cakewalk need to take a review of their code here somewhere with a view to optimization of these buttons. Maybe there's a driver issue, however if Dan gets's something similar I'm wondering if this really is the case with drivers....

May the Cake be with you....

What Dan do you mean?  jkleban says he sees this issue, too. Dan (dke) says he doesn't see this issue. I wonder what audio interface jkleban is using?

Also what I'm insinuating when I say it's probaly driver related is that Cakewalk seems to have to test this issue with the same audio interface and driver in order to reproduce it and fix it. That's what happened when I had the Record Arm issue. Moreover, if I recall correctly, Cake had tested this issue with my audio interface and a different (older) driver version to what I was using, but the lag wasn't there (I was using a new beta driver). So, I think it may be driver related because when they asked me what driver version I was using, and I told them, they came out (quickly) with a SONAR update that fixed the issue for me.

yorolpal


The odd thing about my delay is it is either project or time specific.  It doesn't happen all the time.  In fact, Saturday and today was the first time it cropped up.  And then in a third project it didn't show itself at all.  So perhaps not an interface problem. 

It sounds like there was an issue in your first project. Because the second project used the first project as a source file, it was now on project 2. Project 3 was not related to either 1 or 2, and so the problem is not present. That logic works for me.

What weirdness in project 1 is causing a delay in the writ enable for those tracks? Did you get one of those funky glitches that insert a ton of blank measures at the project? Somehow I had a track that Sonar thought was 100 times longer than I did. Investigation revealed a controller node that somehow got shot about 100 measures down the time line. My machine always ran poorly with that file, perhaps it was corrupted.

I've encoutnered this issue since updating to X1C. I get a HUGE delay when enabling or disabling:

Arm / Record button
Input Echo button
Metonome on playback
Metonome on record

They used to be instant but now I have to wait  for about 3 - 6 seconds every time before the status changes. Doesn't matter if it's an older project or a blank template.
 
I have a Focusrite Saffire Pro 40, the setting are the same as pre X1C update.
 
Thanks
Dean

This has got to be an interface issue. I can't see a way of something inherent to the track causing the same issue in an exported file in a different app. Your computer has no way of knowing it's the same track.

Yea, I know.  That's why it's so crazy.  I loaded up two other files in Sound Forge just to test and they played back instantly.  Then, as I alluded earlier, I worked on a third project in X1C and had no delay lag at all on arming.  I really don't think it's an interface problem else I would be seeing it all the time.  Again, this is the first time since I've been using X1C that it's done this.  And now it seems to not be doing it anymore.  Go figure.
 
Oh yea, I almost forgot, one more crazy thing that yesterday I didn't think was related but now I'm not so sure.  I was working on this particular project both Saturday and Sunday.  On both days...due to honey-dos...I would occasionally be called away and shut my DAW down.  I use an Alesis QS8 as my master controller which is also set to recieve on midi channel one (a particular piano patch I like) and channel 10 (my Clicktrack).  On repowering up the DAW all weekend...and only on these two projects...my piano patch had been changed to some warbling sound with almost no volume on my controller.  Turning it off and then on did not fix it.  Only cycling through the bank selector on the Alesis till I got back to my master setup worked.  So not only was I having internal problems on those tracks it could've been sending out some screwy midi message to my controller on shut down.  And, yes, that problem too went away when working on the new project...unless I were to power it up today and have the same weird sound on my piano track:-)
 
 

I don't see that issue with my system

*Focusrite Saffire Pro26*

Though, and this might help to narrow it down, I'm still on XP32 SP3