Enigmatic
anyway I'm just going to contact tech support... because I'm sure this naming system quirk is some sort of a bug that the experts need to know about.

 
Good luck with that...
 
Personally, I think you are getting too hung up on something that is normally in the background.
 
On the subject of using undo, or CTRL+Z just because you don't like a take... If you are not sure, don't undo the take, just mute the clip. Or, even better, use Take Lanes... It's what they are for 
 
I also use CTRL+Z after a take, but that is because I have usually totally messed it up and there is nothing in that take I can use.
 
cheers
 
andy

I haven't read all the long posts but there is a rule in Sonar's naming pattern

If you start a project and insert audio tracks and name them before recording material to the track then the resulting files will have the name of that track. Otherwise files are named after the project track such and such.

Clips made from existing tracks aren't named at all. There is an internal reference Sonar keeps as clips are only a subset of a file that already exists and won't change. If you render several clips to make a new track that track will be named project such and such track etc.

Enigmatic
 
 
speaking of such you may have different setting than I do because here is a video that shows that Ctrl + Z certainly does not remove the audio from the folder... just saying... here is another video that shows just that
 
https://youtu.be/ZQB2YZPsEhg
 
anyway I'm just going to contact tech support... because I'm sure this naming system quirk is some sort of a bug that the experts need to know about.
 
 

AFAIK, You need to press Ctrl+Z immediately after the take (litterally as the first click after pressing Stop), then the take will not get saved in the audio folder.
In your example (if I followed it correctly) you Undo after several activities. At that time the audio file is already written down, and will not be removed. 
 

mudgel
If you start a project and insert audio tracks and name them before recording material to the track then the resulting files will have the name of that track.

Hi Mike,
 
I think the OP is referring to the last part of the wave file name that is contained within brackets:-
 

Enigmatic
"ProjectName, TrackName, Rec (#)"

I will admit, that there is no way of determining which was your last take because, although not exactly random, you cannot be certain which "ProjectName, TrackName, Rec (number)" other than looking at the date stamp of that file, which is what I'm suggesting the OP should do, in this case.
 
I never use Sonar's file browser and if I want to drag any external wave file into a project I do so from windows explorer...

Okay... just watched the video and the only thing that, to me, is not explainable is when that one clip number switches from one number (8 I think) to 10... but I may have overlooked why that might be.
 
So going through the stuff one at a time...
 
The first clips you recorded into track one are stereo clips so it is naming them in multiples of 2 because although they are one clip they are 2 recordings (left and right). Perhaps if you split the clip to mono they would show up as 1 and 2... not sure.
 
Then when you record in the second track you are recording as mono so the clip number only goes up in crements of one. Remember those numbers represent the RECORD number and technically a stereo track is two individual recordings.
 
As far as when you changed the clip name in Clip Properties and it not being updated in the Browser, did you refresh the Browser (I think you just hit F5 but I think you can navigate away from the folder then back). I don't think the Browser auto refreshes but I am not certain.
 
Anyway, I was talking about getting right inside the folder outside of Sonar using Windows Explorer, not the Sonar Browser, to search and sort your files. As I said, between the Date and Time sort options it's not too hard to hunt down specific clip/recordings.
 
That thing that happened when the clip name changed to (10) though was indeed odd but someone smarter than I could perhaps watch the vid and find a reason for it.
 
Edit: Okay, I just saw the discrepancy between the names right on the clips and what is being shown in the browser. That is screwed up and I wouldn't mind knowing what the reason is. If you found out the answer please update the thread and post it.
 
Cheers.

I too use CTRL+Z to immediately undo any recording that I know didn't go how I wanted.
 
If there are a lot of fragmented clips for a project, over time, that aren't actually still used by the project, I will often do a Save As for the project, to a new folder, and I will use the Copy All Audio option.  This will copy over only the audio clips actually still referenced in the project, and I do this to get rid of all the space consumed by the unused clips.
 
I also name tracks prior to ever recording to them.
 
Bob Bone
 

- Cakewalk/SONAR has never maintained any strict correspondence between clip names/numbers in the GUI, and file names. Count your blessings; it used be a lot more difficult to know what's what with names like RLKFOTDMPTNGHDGK.wav.    Pre-allocate files created when arming tracks can cause file numbers to increment without the clip number being incremented in the project when you actually record something.
 
- If you haven't lost a link between a clip and a file due to a crash or inadvertently deleting and saving, you can find out what file is associated with which clip by right-clicking and choosing Associated Audio Files (shift+K).
 
- SONAR does not remove clips for unused takes from a session until you close the project. Any new file not referenced in the saved project at that point will be deleted on closing the project, but any file that has ever been referenced when the project was saved will continue to exist even after all references are deleted from the project until you use Clean Audio Folder or CWAF tool to clean up the folder or otherwise manually delete it.
 
AFAIK, this is all working as intended. If you want something to change, it will need a Feature Request rather than a Problem Report.
 
 
-