X3 does not record take lanes correctly in my scenario

What I see is the Input on the Audio Track [StrASFUA...]  not matching the Output of the MIDI track [3SpuDm...]. Might be something there.
 
Are you using an elect. drum pad kit or SupDru grooves? Either way, these would be MIDI signals that would be transmitted to the MIDI track. The output of the MIDI track is then  routed to an Audio Track to hear them. 
 
I record to the MIDI track and my take Lanes are produced there, not as Audio. If you want to deal with audio for  mixing purposes, you'll need to bounce it from the MIDI clips.
 
In my use I'd have many recorded MIDI clips/lanes all going to one Audio track.
It's also nice to set up the SpuDrm mixer to output on multiple audio tracks, not just a stereo out. Some where in SupDrm  it will do that for you. I usually have to screw around with the panning/stereo-mono choice of outputs at the very least for my liking.
 
Michael 
 

Yes, you'll want to stay away from mixing looping and punching until the sync issue is fixed. But the split clips are a normal part of Comp recording mode. That past partial take you recorded, (and then apparently deleted) caused clips to be automatically split with the first part of the penultimate take muted - replaced by the partial take. You can swipe through and entire lane with the Comp tool, starting outside the clip, to "heal" the splits in all lanes.
 
I've entered a feature request to automatically delete that last take and heal the splits when that last partial take of a looped Comp is smaller than some user-specified length, and clearly just a "leftover".

I closed SONAR, Reopened SONAR and brought the project up again to see how it would record more takes. I found this behavior to be totally unacceptable: Notice that clips were recorded OUTSIDE the punch points. All I did was press record with the track armed. HOW could something like this not get caught in beta? Is there much regression testing going on at all?
 
http://joyfulnoiseproductions.org/takelanebad2.jpg
 

DeeringAmps
"Timing is everything"
Seems basic to me....
Just sayin',
 
T
 
The moral to this story; at this time, don't loop and punch, at the same time!

Maybe there is a product that can do basic stuff like this without errors... Looping and recording is a lot of my workflow. Putting up with this recording behavior is really irritating me.

Guitarmech111
Notice that clips were recorded OUTSIDE the punch points. All I did was press record with the track armed. HOW could something like this not get caught in beta? Is there much regression testing going on at all?

You can't catch something in beta if it doesn't happen. I've not seen this reported by anyone else on the forum which means it may never have been observed - much less replicated for reporting - by beta testers.
 
Based on where the splits are, I would have guessed they were moved after recording was complete. But I'm also seeing that your take lanes are out of order so I'll take your word for it that this just happened spontaneously. In any case, I suspect  your test project has become corrupted - possibly by repeated "undo" operations -  and you need to start over with a fresh one. Continuing to use the same project to show different buggy behaviors after it's already been shown to have problems isn't very useful.
 
And if you can come up with a reliable sequence of events for replicating that problem in a new project, you should report it to the Bakers.
 
 

This was a brand new project, FRESH 5 minutes before I posted the error.
 
My subsequent error occurred by opening the project and hitting record with the track armed. nothing else.
 
My default at that time was sound on sound, not comping.

I had the recording settings on Sound on Sound. Not my fault if the graphic didn't change.  ;)
 
I just changed it after Alex pointed out the comping default in his reply to me. The record button still didn't change after that switch. Maybe it is a situation where you have to change the parm and then change the parm back to get what you actually want. Kind of like those buffer settings Alex and Craig were talking about.
 
All I know is that I had SOS default when I reported the error because I changed it to comping AFTER Alex replied to one of my posts.