It seems there’s still a problem with clip names being corrupted. The clips in the screenshots were correctly named when opened (a). I deleted the first two clips (b) and inserted two clips at that point (c). You’ll see the other clip names have been replaced by ‘Music Track n’. This issue has plagued clip names since they were introduced and it’s not worthwhile naming them while it persists.
I’ve tried to replicate this on W10 with 3.1.3 using some simpler steps (so that a bug may be logged) - but I can’t reproduce this.
@Bran Smith: any chance you can reproduce this with a simpler scenario (fewer clips, single track) with detailed steps to reproduce, to make this happen please?
You say that you " inserted two clips at that point (c)" - exactly how did you do that please?
@Peter: I’ll do ask you ask but I have a lot of shows to record, so it’ll be later this week.
I double-clicked on ‘Winter Wonder’ to select, then F9 to add the short clip before it. I deleted them, then selected ‘Ding Dong, Ding Dong’ and the short clip before that from another project, then inserted them at the cursor point. That’s when the clip names were corrupted. I’ll try moving clips separately to see whether that affects the issue.
Found it - the issue occurs when moving multiple clips, which wrecks the names of subsequent clips. When they’re moved separately the names are preserved. The obvious solution is to move them separately but it’s worth investigation and correction.
@Peter: I noticed you were working within the same track. My clips were moved from another project, perhaps the answer lies therein. It’s not my place to tell the developers their job but I would investigate the code where clip names are entered, which seem to be based on the track name. If a clip name has a null value then enter a generated name; if it already has a value then leave it. Once a programmer…
@Peter: I also discovered by accident that multiple clips can be moved - very useful! Further use since my last comment shows the same results when moving or copying clips, single or multiple, from one project to another. That’s select, copy or cut from one project, paste at a cursor in another.
Post-release bugs sometimes arose from the way people used (or misused) the system - ways that weren’t contemplated in the specification or design. A colleague used to say “that’s not a bug - it’s a feature!”, and sometimes got away with it.
well I’ve tried copying and pasting single and multiple clips from one project to another back and forth - and I still can’t get any clip-label corruption
That’s users for you - they will go and use (and bend) systems in ways you never thought of as a designer/developer, that a;ways used to amaze me
I heard that many times in Audacity over the years when I was working on the QA testing and logged bugs in the old Bugzilla bug-tracker. And that could lead to some “spirited” discussions.
@Peter: That’s quite a litany! As far as I’m concerned looping is a feature too far (and caused me continual annoyance before 3.1.3) but it could be the answer to another user’s prayer.
The fact that we’re getting different results from apparently the same actions makes me wonder whether it’s the way I operate. We learn most software by trial and error, when all else fails we RTFM (read the flippin’ manual). Remote support often obscures things that being on-site makes immediately apparent. Clip names are relatively new; I did without them for years and would never have thought of requesting them.
I’m enjoying this exchange but am conscious of taking up a lot of your time. When 3.1.3 becomes more widely used others might experience the issue. I’ll keep at it and will report if I uncover the reason.
@Peter: I missed your most recent post while I was writing mine, relieved to see it’s a known issue and logged. I’d been getting that “is it me?” feeling. I imagine it’ll take its turn and be fixed in the course of time. Many thanks for your input, wishing you a safe and happy 2022!
I have added a “nudge” to the bug thread to try get get it’s priority raised a bit and to try to gain it visibility for inclusion in the list of bugs to be addressed for 3.2.0.