View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000502 | ardour | bugs | public | 2004-05-31 09:24 | 2009-07-05 01:42 |
| Reporter | vandongen | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000502: region naming scheme truncates too much | ||||
| Description | If I rename a region with a name that includes a dash , making an edit truncates the name to the first part: I bounce around and create a region that I rename cool-solo, and then if it is split, I get cool.1 and cool.2 If I name it cool-solo.0, it will still only keep the first part. The assumption here is that the dash only occurs on takes. And it is unclear why the take number has to dissappear anyway. | ||||
| Tags | No tags attached. | ||||
|
|
It is even stranger. I have a region called "peter-verhaal" I seperate a range in the middle and I get the following regions: peter-verhaal.2|peter.1|peter.2 |
|
|
so, how best to fix this? use a different character? enforce its non-use in the region name? look for the special character only before the final digits of the name? any thoughts? as to why we don't keep the take number - it remains on the "whole file" region that is always in the region list. regions in the playlist itself don't need to contain that information, since arguably, once they are edited, they "are not" the original take. the buddha was walking along a road when he met an audio engineer. the audio engineer cried "oh buddha, oh buddha i just recorded the sound of the lotus flower blossoming. and now i have two recordings of the lotus, one called lotus-1 and one called lotus.1. can they be the same? can they be different?" and the buddha replied "they are the same. they are different" |
|
|
I think it is complicated for something so seemingly simple. First, why take numbers: I record two takes of solo. That gives me two audiofiles calles solo-1 and solo-2. Now I start to cut and mix and I want one part of solo-1 and another of solo-2. What you have now, is that there is now way to deduce the source by the region name. Unless I rename them immediatly after recording to f.i. GoodStart and GoodEnd. Which is what a discplined engineer will do of course. A cool feature would be to have the naming set by something similar to the PS1 variable for bash. Anyway, there are two systems at work, one is the creating of audiofile names based on track/take or inputfilename/channel (when importing). This by it self works fine, but could eventually be improved. The other system is the creation of region names during editing. And here is the problem. My proposal: A region in a playlist is always in the form somename[.number] If the user tries to insert a audiofile, f.i. audio-1 the wholefile region will be inserted. So that is audio.0 now and my preference would be audio-1.0. If the index needs to be changed the name is parsed for a ".number" extension and if present this will be adjusted. You can't just increment it because that might allready be present. Instead the new number will be the next _unused_ index number for that name. Or maybe the biggest used number + 1 . Not sure what would be nicer if there are gaps in the indexing (after removing regions) - filling the gaps or ignoring them. If there is no number extension because the user renamed the region, you just add a .1. There is no need to parse for dashes, and if a user wants to call a region foo.3 even if it has no relation to foo-0 they should not be surprised that the edits result in foo.4 or foo.17. So this way lotus-1 is in the region list as a parent node, but will never appear in a playlist. And the buddha will say, they are but different reflections of the same truth. |
|
|
This seems to be fixed in recent versions of Ardour(2.8 or newer) Regions now mantain the hyphens correctly as far as I can see. Resolving out the issue. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-05-31 09:24 | vandongen | New Issue | |
| 2004-05-31 09:24 | vandongen | => gml@xs4all.nl | |
| 2004-05-31 09:33 | vandongen | Note Added: 0000922 | |
| 2004-06-01 20:34 | paul | Note Added: 0000932 | |
| 2004-06-01 20:35 | paul | Status | new => feedback |
| 2004-06-02 09:00 | vandongen | Note Added: 0000942 | |
| 2009-07-05 01:42 | seablade | Note Added: 0006277 | |
| 2009-07-05 01:42 | seablade | Status | feedback => resolved |
| 2009-07-05 01:42 | seablade | Resolution | open => fixed |
| 2009-07-05 01:42 | seablade | Description Updated |
