bvideo

The next thing I would check for is midi routing. Maybe there is some kind of midi storm or at least duplication of data going through the Roland or going to Pianoteq. I don't know if MidiOx might help diagnose this or maybe examining the event list of the track you are recording for Pianoteq. So also check your MIDI tracks' channel configuration (setting a single channel instead of omni)  and make sure echo is off  and make sure "local control"  and "thru" is off for your keyboards.

Is midi going through a midi interface or a USB connection? Any further details would help: make, model, hub?

So when the transport gets stopped, those sounds won't match how you set them with those controllers. The "chase" setting should put them back where they should be wherever you restart, but if you want to play those instruments or edit notes, etc., after stopping the transport, they won't sound right. Come to think of it, it's kind of inconvenient to have controllers modifying sound when you go to edit at different points in the timeline.

I don't know the answer and I don't disagree with your suggestion, but in the absence of the "all notes off" option, maybe there is some existing workaround to whatever issues you have with "Zero Controllers...". Can you describe a situation that zero controllers messes things up?

Can anyone say what should happen with dim solo in that simple case?  When track 1 is soloed, then would track 2 be dimmed as it goes out to the patch point? Then track 3 dimmed also, double-dimming the sound from track 2? How should double-dimming be avoided? And did such attempt to avoid wind up being the source of the no-dimming on track 3? More complex routing would probably have even further hazards.

Is the studio live f/w up to date? Sample rate you're using in Sonar/Cakewalk matches the device setting (in Universal Control) ? Are you using DAW mode or interface mode? USB presumably?

Maybe the Soundcraft signature series 12 MTK is only capable of 48KHz recording. What sample rate is your project set at? What sample rate does Cakewalk think the Soundcraft can do? Are you using a soundcraft driver? ASIO? Asio4All?

19 hours ago, Goga said:

Hello dear sirs!

I have a question about Tempo Track.
If there are many tracks involved in the project and a change in the tempo of the project is registered in the Tempo Track (increase in speed, decrease in speed), then in places where the tempo changes, the sound begins to crackle.

The computer is powerful enough.
Windows 10

10th generation I-7 processor.
System Disk-SSD
64 gigabytes of RAM.

Changing the delay in the audio interface didn't change anything.

Interface - Antelope Audio Zen Go.

Is it like this: "tempo based delay and noise"?

Impressive!

Do you mean external synths?  Misbehaving MIDI interface, too many thrus, bad or too long MIDI cables...

Can you make a shortcut to the "panic" (all notes off) button?

(The Reset MIDI and Audio button in the Transport module)

If you truly mean a MIDI track, what is the thing that should be generating audio? Is it an external device which you have wired to send audio back into cakewalk? If so, you would need to make sure that device's audio track is grouped with the MIDI track's solo button so it doesn't get automatically muted along with all your other tracks.

What did you mean by 'peaks'

Back there you said "peaks, clicks, etc.". Clicks could be a performance issue, but what did you mean by 'peaks'; also 'etc.'? Is there some audio distortion happening that could be independent of performance issues?

As a point of information, try recording one of those non-controllable patches from the keyboard, then see how that bank & patch is labeled in the event view of Cakewalk. To be complete, make the keyboard change banks as well as programs as you record. The event view might work as your debug log. You can open the event view by selecting a track and pressing ALT-8.

Dirty console emulator?

Also, if you're using firewire & WDM drivers, try ASIO.

30 minutes ago, John Vere said:

I myself don't understand why you would need such an item? I've been using Midi for a million years and it has never changed much since day one in the 80's. 

It's data. That data flows to an instrument where it becomes audio and from there on is treated like any audio. This could be a VST instrument or a Hardware instrument (or a Lighting rig or a smoke pot. ) 

You can manipulate that data on it's way to the instrument in a zillion weird ways with controllers and other data that is added to the data stream. The common ways are CC events ( CC7 ) and system exclusive data packages. 

A midi signal flow chart will be a straight line with little boxes added in the path where you alter the original data. 

A straight line with boxes would not be able to explain anomalies in the mute & solo & input echo parts of the MIDI signal flow or how prerecorded material merges with live input or the entanglements with instrument tracks and their synth components.

Disclaimers: I didn't watch any of the videos you did, and I don't know if your laptop has a LAN (ethernet) port. But if it does, and if you aren't using it, there are some designs for laptops that trade off hardware for software, which could cause the bad latency. In the software case, the software has to service a special part of the LAN at high priority in a loop. It's worst when the LAN port has no connection (no cable or nothing at the other end of the cable). Not even sure this would show up in wdf01000.sys, but if you haven't already, it's worth trying to disable the LAN interface if you have one.

Seems wdf01000.sys is a module that can be coupled with other driver modules for many different devices. The latency reporter combines the report for all devices that use that module. Finding which device is invoking that module with the outrageous processing times is a puzzle.

8 hours ago, chris.r said:

That, I would call a design flaw, rather than bug. I mean, in Windows, is an app not being able to distinguish perfectly between different devices connected? I thought each device has its unique signature number or something. If so, then it should be easy for the DAW to assign an internal number for each respectively... and not mess with the numbers later on.

For USB devices, the establishment of uniqueness depends on the type of device. Disks and many other device types have unique identifiers down to the serial number of the individual device. Unfortunately, the USB MIDI class was defined without a serial number, just vendor ID and product ID. So two devices of the same make and model are not distinguishable. Can they be distinguished by which hub and port they are plugged in? Maybe, so don't ever shuffle them. Do Cakewalk and Windows do everything that could be done to uniquely identify devices, I'm not sure. But it's definitely an imperfect situation in the USB MIDI specs.

Save a backup & be happy. Seriously don't worry, you won't screw it up.

If you don't see those variables in the [options] section of TTSSEQ.ini, cakewalk uses the default values. The file most likely for you to add those variables is %AppData%\Cakewalk\Cakewalk Core\TTSSeq.ini  (where %AppData% is based on your windows ID).

Is the flaky project gone or still saved somewhere? I love looking for mysterious noises. If it's still around, strip it to the least audio that still makes noise, as John Vere says, and send it to the cloud.

I wish it were more clear to me what the role of this 7/8 loop is in this 4/4 project.

Bounce the whole thing then edit is one way to go. All  your notes are preserved, but the loop property is lost obviously. Another way is to snip off where you want to edit and bounce just that part, leaving the loopable part as it was.