bvideo

On the off chance that your goal is to be able to use "snap" alignment to a point other than your clip left boundary, see "Snap Offset". You can create a snap offset for a clip by setting the "now" marker where you want "snap" (e.g. beat) to be aligned, then right click the clip and set the snap offset to the "now" time. In your example, you would set that 1.36 ms after the start of the clip. Then when you move or copy that clip when snap is enabled, instead of the left edge aligning to snap, the snap offset aligns to snap. You can think of this as a way to have the clip start playing ahead of the beat where it snapped to. Of course the clip will not be visually aligned on the beat, but it will be visually aligned with where it actually starts playing.

Rufus method can also do a clean install. The installation disk modified by Rufus can supposedly work either way.

Two of my PC motherboards have a provision for adding a 'tpm' which is a small dongle that adds a supposedly required security function. That was enough to elevate those machines to be W11-ready. Around $10 each.

So you're starting with no audio in Sonar. In that scenario, Solar can probably follow an external clock. But Cakewalk might balk if it has audio in any track and you ask it to follow timecode. How about your audio interface. Can it follow a sample clock?

Does the project have audio?

Is this Midi going to a h/w synth? If so, what about your interface? Also, does your transport stop moving or does it continue playing the following measures?

You were able to work your keyboard without the M50 editor. That suggests that the editor is not passing its input forward to the MIDI output. I think we know the editor can send to the output, but just doesn't pass forward its input. That's either a major bug or there is some config item in that editor that suppresses that routing. In Sonar there is a taskbar widget (maybe optional?) that shows two little red dots. One shows input received, the other shows output sent. What do you see there?

The m50 may not be producing sound from playing on its on keyboard because its MIDI "local control" is off. That is a preferred and perhaps default function of Sonar to send to MIDI ports when it starts up and addresses the MIDI connections it has. That's a setting that can be changed. Generally, "local control off" means Sonar intends that you set up the track's routing with "echo on" so that all performance goes in to a Sonar track and then back out to the keyboard. Suitable track settings for input and output are required. And whatever MIDI effects are on the track ought to pass output for any input.

The single "c1 note on" does seem weird. Some of your "note on" events could have 0 velocity, which means note off. "midi/usb lead": if it's a typical midi/usb adapter, one midi connector is input & the other is output. Also, you could mention the make & model of your adapter, in case it's one that is known bad. "timing clock" may be configurable in the synth. Or maybe midi-ox can filter it out of your display. Also active sensing.

It's possible to zoom all the way in to the sample resolution. See anything then?

IRQ conflicts used to be a thing. Now not so much. IRQs used to go to "15" on early PC hardware. Now, if you look at your "System Information" under the [-] hardware resources -> IRQs, you see numbers up to 511 at least. And no conflicts. This was taken care of by hardware improvements in PC architecture, including an "Advanced Programmable Interrupt Controller" and also "Message Signaled Interrupts". Software improvements include "Deferred Procedure Call" (DPC), which offloads traditional (old fashioned) interrupt processing to lower priorities (and also allowing for use of all the cores to do device servicing). Nowadays, when looking for hitches and sputters, it is frequently in some DPC, and Resplendence LatencyMon is likely to point out which ones cause the problems. Some older network interface drivers used to be somewhat of a problem, especially if your cable was unplugged, because they would run high priority loops to detect the cable status.

Ram makes a difference when you use a sample-playing vsti. It might be helpful to say a lot more about the projects you have: audio? midi? softsynths? number of tracks? sample rate?

How about "envelope segment shape"? You can change the straight lines between nodes to curves. Perhaps your envelope nodes happen at inconvenient points in the wavevorm where a sudden change in gain causes clicks. Perhaps using a curve makes the change not so clicky.

To eliminate certain artifact-producing settings, you could see if it happens with 64-bit audio set/not set and plug-in load balancing set/not set.

What counts more than anything is the input setting on every MIDI track. (User 905133's initial assumption).