Thanks...

I am JUST awaiting for others with this issue (see my steps to repro) so we can at least narrow it down and get some facts. So far there's one person who will hopefully get back.

---->

STEPS

a) Goto track view
b) Play and stop song using the transport provided.
c) Arm/Disarm record on many tracks (whilst track is stopped). e.g. Record = on or Record = off

EXPECTED
Arm record button instantly presses/depresses and is responsive within the UI.

ACTUAL
Arm record takes a very long time to respond in most instances before they turn red.

NOTE!!!!
Record arm buttons are set in preferences NOT to be functional during playback (as per default).
i.e. Allow arm changes during playback/record" = disabled

AND AGAIN PLEASE NOTE

Delay are also happening when enabling or disabling:

Arm / Record button
Input Echo button
Metonome on playback button
Metonome on record button
WHILST THE SONG/PROJECT IS NOT PLAYING.

64 BIT X1C ONLY RUNNING WINDOWS 7
So far it's just me and one other who both have Saffire Pro 40s it seems!

Please only reply if you can repro EXACTLY, please state your drivers/driver versions, hardware, and whether you are running 32/64 bit... thanks!

OK here we go.

When a driver has to communicate to SONAR, I see that as a time based process. If there is a less than optimal response time in that communication, I see that as latency. That's what I mean when I say it's a latency problem. So, brundlefly is correct about what I mean.

Look, guy, getting to the bottom of this issue requires troubleshooting. That is all this is that I'm suggesting.

But, since you display an attitude that suggests you know you're on the right track to getting your issue resolved,  which is something I beg to differ with, I'll back off for a while.

I'm really just trying to help. Goodluck. I'll be following this thread.

By the way, when you report something to Cakewalk as a bug, it is possible that they will contact you for further information, and they may have some things which they may suggest you try to help them resolve your issue. So, just becasue you didn't contact them for technical support doesn't mean you, absolutely, wont hear back from them.

Have a good day. :)

I see Alex's problem, he is using a DELL.  :-)

Jim

> I think tomorrow I will plug back into the mobo firewire port and roll back to mix control 2.2 and cross my fingers.
Thanks Dean, but please don't do both at the same time :).
Check to see if the other firewire port works with 2.4 before you roll back.
If rolling back to 2.2 works please let me know your current driver versions... then I'll have a go and we can compare notes!

Also I assume you are using the legacy firewire driver under device manager/IEEE 1394 (it's the only way to avoid those CPU spikes).


Cheers....

UPDATE - I couldn't wait - I Just logged an issue with Focusrite.

Weird, Dean when you are on 2.2 what's the difference in your Help/About In Mix Control, mine:

Pro40-0331e - Firmware 1501
HardwareID: 13086
Pal Base: 3.5.3 (8786)
FW-Driver: 3.5.5.10705
Revision: 1782

You are using legacy 1394 Firewire driver?
You downloaded a fresh copy of 2.2 from the Focusrite site?

Thanks.

Add me to the list.. I had the same problem. I had the latest Focusrite Mixcontrol 2.4 Beta version installed with the 3.6 driver. I read this thread and uninstalled the mixcontrol and installed 2.2 and everything is fine. I am using SaffirePro 24.

For anybody who can't get 2.2 drivers working, please try later beta versions on Focusrite's beta download page. Here's what Focusrite support had to say about my 2.2 installation (or "near" 2.2 installation):
 
Pro40-0331e - Firmware 1501
HardwareID: 13086
Pal Base: 3.5.3 (8786)
FW-Driver: 3.5.5.10705
Revision: 1782
 
The FW-Driver version is the wrong version for Saffire MixControl v2.2, it seems like this may have come from a beta version as it should be 3.5.3.8786. However, if you have a working version of the driver I recommend not changing anything as our developers seem to have found the issue present for the correct driver for v2.2 (although I could not).

@CakeAlexS, I am not sure the latest beta drivers have the fix. I was using the latest 2.4b4 version and had the same issue.

Saffire MixControl 2.2
Pro24 - Firmware Version 1501
Hardware ID: 13459
PAL base: 3.5.3(8786)
FW-Driver: 3.5.3.8786
Revision: 1782

If our main wish is a stable daw - I think we might have to live with some delays to protect switching complex contexts.

A daw is a complex s-hit with everything it can do.

OPs first post says nothing about how long it takes - which would have been appropriate.

Three seconds - yes that sounds a bit slow.

Not instant - that's ok.

Some post I read over the years where people are doing the most unlikely stuff while transport is running and expect everything to run without even a glitch, pop or crackle - I don't really understand.

One thing - why would you need to run transport if inserting a new synth or plugin?
I never even thought about doing something like that.

Why do you need it?

Just my view....

CakeAlexS


Thanks...

I am JUST awaiting for others with this issue (see my steps to repro) so we can at least narrow it down and get some facts. So far there's one person who will hopefully get back.

---->

STEPS

a) Goto track view
b) Play and stop song using the transport provided.
c) Arm/Disarm record on many tracks (whilst track is stopped). e.g. Record = on or Record = off

EXPECTED
Arm record button instantly presses/depresses and is responsive within the UI.

ACTUAL
Arm record takes a very long time to respond in most instances before they turn red.

NOTE!!!!
Record arm buttons are set in preferences NOT to be functional during playback (as per default).
i.e. Allow arm changes during playback/record" = disabled

AND AGAIN PLEASE NOTE

Delay are also happening when enabling or disabling:

Arm / Record button
Input Echo button
Metonome on playback button
Metonome on record button
WHILST THE SONG/PROJECT IS NOT PLAYING.

64 BIT X1C ONLY RUNNING WINDOWS 7
So far it's just me and one other who both have Saffire Pro 40s it seems!

Please only reply if you can repro EXACTLY, please state your drivers/driver versions, hardware, and whether you are running 32/64 bit... thanks!

OK Alex.. this may help. My specs are in my sig.. and I hope I've given enough detail to give you a better idea of what may be going on.. I've got to leave for work so I apologize for not being more elaborative.. I'll do more later.
Dave
 
[size=3 font="times new roman"]Under Saffire mix control ver 2.2
[size=3 font="times new roman"]Firewire ver 3.5.3.8786 rev 1782
[size=3 font="times new roman"] 
[size=3 font="times new roman"]I didn’t have delayed record/input echo at all. Clicked on/off instantly
[size=3 font="times new roman"]In X1 expanded 64 bit, sonar pro ver 8.5 32/64 bit
[size=3 font="times new roman"] 
[size=3 font="times new roman"]Updated to Mix Control  ver 2.4 which automatically
[size=3 font="times new roman"]Updated Fire wire driver to ver  3.5.6.11675 rev 2422
[size=3 font="times new roman"] 
[size=3 font="times new roman"]Experienced very slow response to record/input echo click on/off
[size=3 font="times new roman"]In X1 Expanded, Sonar pro ver 8.5 32/64 bit
[size=3 font="times new roman"] 
[size=3 font="times new roman"]Rolled mix control back to ver 2.2 which automatically rolled
[size=3 font="times new roman"]Fire wire back to rev 1782 but the driver version remained 3.5.6.11675
[size=3 font="times new roman"] 
[size=3 font="times new roman"]Experience same VERY slow (if not SLOWER) response to record/input echo click on/off.
[size=3 font="times new roman"] 
[size=3 font="times new roman"] 
[size=3 font="times new roman"]Note:  Fire wire is on board TI TSB43AB23 chip 400mbps and the ver 3.5.6.11675 driver must be the culprit. I’ll find out when I do a system restore to remove the recent fire wire driver update.
[size=3 font="times new roman"]This is apparently NOT X1 related!
[size=3 font="times new roman"] 
[size=3 font="times new roman"] 
 

"Just responding - not trying to help."


me too-all 3 of my focusrite interfaces(Sapphire 6 usb,OctoPre fw and Liquid 56 fw) were rock solid,instantaneous and glitch free straight out of the box with the supplied drivers but then i`m only using the obsolete 8.5.3.

CakeAlexS


THE ISSUE IS WITH SAFFIRE MIX CONTROL 2.4 AND SONAR X1 (64 BIT)
End of.
(damn it why don't people read)
 
Oh and if you read the thread you would realise this is nothing to do with running transport Ifm....
> Just responding - not trying to help.
Thank you for your contribution (in turning this into a debate rather than a diagnosis).

Alex.. I only (after X1 64bit test) tested sonar 8.5 32/64 to TEST the problem presented.. I did NOT have any slow response issue in any of the versions. NOW, ALL versions have the problem you decribe. (why did I do it!?.. update my mc driver? to like, isolate it to a specific version of Sonar?.For DIAG SAKES! The attempt to isolate it to X1 failed, IMO. Please re-"read" my post above. The issue is running through both X1 and  sonar pro 8.5 32bit or 64 bit(doesn't matter. The 8.5 version both 32 & 64 developed the same, exact problem as did X1 which was NOT there before I updated MC2.4). Which leads me to believe this problem is FIREWIRE driver in the Mix Control 2.4. Again, please re-"read" my post. 
 
All that said, now I'm going to restore my system and try to rid it of this.
Best regards,
Dave
 

Done (hissy fit over :-).
Thanks Dave.