But then why would it only happen in those two projects and not the very next project worked on only minutes later??

Hi Alex:

You said you reported this issue to Cake. Can you let us know what they have to say when you hear back from them?

Hi Thomas

I haven't reported this issue to cake as a support issue. Rather I filled a bug report (perhaps mistakenly, not sure) whereby I don't expect a full response.

I'm waiting for Dean and Yorolpal responses to my previous post, and anybody else who cares to chip in with this specific issue. So far it seems it is limited to Focusrites and/or possibly firewire devices in a 64 bit environment, so I need more in depth info on drivers, OS's etc. I want to see what we all have in common here.

Well, then I'll certainly be on the lookout for it to crop up again...and keep ya posted.  But, as I said, it had not happened before with any iteration of X1 and, so far, has not happened since.

Yoropal would you mind posting your driver versions/mix control versions (if running) anyway so we can rule it out? See above... thanks.

I will say this, that in my case, two new things were involved for the issue to become noticeable:

1) I switched from a PCie audio card (Echo 3G) to the Octa Capture
2) Working on a previous project where I used MIDI and virtual instruments to trigger the midi performances but moved over to tracking live and added a lot of audio tracks (really not too many).
3) The problem seemed to become less of an issue (but still an issue) when I created more track folders and moved some of the audio out of one big folder.

I am on X1b, x64 WIN 7. I get the lag of the RED RECORD video but the system does start to record even though the arm visual hasn't yet appeared.

My feelings are it has something to do with the new card being USB instead of PCIe. I do not have a PC that supports USB3 so I am using USB2.

But in my case, the driver is made by ROLAND and one would think that they would have had this flawless with their own flagship DAW software?

So, perhaps there is a way to optimize the USB ports for speed that I am not aware of (or perhaps I turned something off in WIN7 services that should now be on)?  I am not a PC wizard so I depend on things just working when I plug them in.

I can't tell you how disheartening it is when you never know exactly when the SONAR NOT RESPONDING issue will reveal its ugly head but I know that after so many minutes in a session, it is just a matter of time before it does.

I didn't have nearly as many issues before the OCTA CAPTURE or AUDIO TRACKS difference in my workflow. 

I should try a new project and see if this happens as well in a new project file or it is just this older one that I have been working with.

I hope somebody comes up with the culprit just so we have an idea on how to fix this ugly beast.

Jim

So, I did a little test and found out that if I have NO tracks armed, that the response time of the GUI dramatically improves.  The real problem is only when there are ANY tracks ARMED for record (even if only during playback without RECORDING turned on).

I know that this doesn't go with the OP symptoms but it is related to the same symptoms.

So, I just need to UNARM all the tracks while MIXING and I should be OK.  But, this doesn't address the SLOW GUI when any TRACK is ARMED.

Jim

Could we stick to the specific issue in my original post please (otherwise create a new thread). I am trying to narrow things down, and it can get confusing when people are stating completely different behaviour, with different software versions.

Hopefully we will get some response soon from Yoropal and Dean, and perhaps any other users who may have this same and exact issue (again please see the first post).

Much appreciated....!

CakeAlexS


Could we stick to the specific issue in my original post please (otherwise create a new thread). I am trying to narrow things down, and it can get confusing when people are stating completely different behaviour, with different software versions.

Hopefully we will get some response soon from Yoropal and Dean, and perhaps any other users who may have this same and exact issue (again please see the first post).

Much appreciated....!

Excuse me, I understood jkleban WAS having the same issues, just using a different interface.

I pointed out he was using a different software version to eliminate that as being part of HIS cause.

Thus rebuked, I shall not be 'trespassing' on YOUR thread further, although if his behaviour remains the same after he installs the C patch you maybe looking at the same behaviour on a different card which makes a specific driver issue look more tenuous. 

I genuinely thought I was helping narrow down the issue here rather than thinking I was gatecrashing an elite club.  Clearly I was mistaken and for that I apologize.

Thank you.

thomasabarnes


Man, y'all just have me laughing my butt off. :)

Shhh, they're trying to concentrate.

Sorry, didn't get a chance to login to the forum last night.

My specs are:

Windows 7 Home Prem 64bit
Sonar X1C 64 bit
Focusrite Saffire Pro 40
Saffire Mix 2.4
Firewire Driver: Not sure will have to check tonight.

The only other thing I can think of at my end is: since the X1C update i've been using my Firewire PCI card and not the Firewire Port on the mobo.

Hope that helps and have a more serious look into it tonight.

Dean

The only other thing I can think of at my end is: since the X1C update i've been using my Firewire PCI card and not the Firewire Port on the mobo.

 
Adding and using a firewire card is a significant change that could be the source of the problem. What PCI firewire card is it? Is it a TI (Texas Instrument) chipset base firewire card?
 
In Device Manager under IEEE 1394 Bus Host Controller, what does it say: 1394 OHCI Compliant Host Controller, 1394 OHCI Compliant Host Controller (legacy), Texas Instrument 1394 OHCI Compliant Host Controller, or what?
 
Users have reported better results by updating the IEEE 1394 Bus Host Controller driver to 1394 OHCI Compliant Host Controller (legacy).

Hate to burst your bubble, but the firewire chipset is important and can have a significant impact on the performance of the audio interface.

It has been reported here in these forums that some VIA based firewire chipsets can be problematic and can produce results of the types of latency problems that have been reported in this thread. Do some listening and experimenting and you just might learn something.

If I were any of you with an exclusively firewire audio interface experiencing the latency issue/s reported in this thread, I'd get a TI based chipset and see what results I come up with. There are some good ones that are not expensive. Like this one, for instance:( http://www.guitarcenter.com/ADS-Tech-Pyro-PCI-64R2-703159-i1600344.gc ) A number of us have already been there and done that. And discovered that a TI based chipset resovled a number of latency and performance issues when using a firewire based audio interface.

Roget that. Jim is an expert! myolpal's issue seems to be related to corrupt projects. :)

This is not a latency issue.

thomasbarnes was using "latency" in the generic sense of getting a delayed response to an action.

The fact is that they are not handshaking optimally specifically when opening/closing ports. The cause of what this could be is mere speculation right now, and speculation is what I'm trying to get away from 

I would call the suggestion that it's a Firewire chipset problem an "hypothesis" not just speculation. You can't troubleshoot a problem without developing and testing hypotheses. And as far as I can tell, you haven't done anything to rule out the FW hypothesis.