View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000344 | ardour | features | public | 2004-03-19 15:11 | 2024-03-25 07:47 |
| Reporter | marukqs | Assigned To | |||
| Priority | low | Severity | feature | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Target Version | 3.X | ||||
| Summary | 0000344: Edit the region in external audio editor | ||||
| Description | Popular multitracks as Cubase or Cakewalk allow to edit the selected audio data in external WAV editors such as SoundForge or CoolEdit. It is not easy to edit the recorded in data in external audioeditors which allow to do such common tasks as denoising, etc. | ||||
| Tags | No tags attached. | ||||
| Users sponsoring this issue | ||
| Sponsors List |
Total Sponsorship = US$ 50 2012-03-20 11:15: realhangman (US$ 50) |
|
|---|---|---|
|
|
this requires either (1) support by external editors for the notion of a "region" or (2) writing the region to disk before editing. regions are not files (and in fact, future versions of ardour may support regions that use multiple files). i do want to add this feature, but its highly non-trivial. |
|
|
I'm marking this as a feature. |
|
|
Hi, (author of ReZound speaking) I've recently completed my first semi-large project using Ardour2 and it's really incredible stuff. Thank you! Concerning this feature request, I also found that my typical work-flow could benefit from being able to edit clips in an external editor. I considered diving into the code and trying to implement this as feature to contribute back a little to the project, but first I figured I should check the latest alpha releases and feature requests to see what, if any, work had already been done on this. So, I found this bug report / feature request and a few questions are raised by Paul's comments. Could you explain a little further about what was meant that (1) an external editor has to be aware of regions? Do you mean to say that a region is possibly a collection of files instead and not just one? I'm wondering this because of (2). Could the feature request be a little simpler by allowing the user to select an actual audio file to be edited and not selecting specifically a region? Is this even feasible in complex mixes from a UX perspective? If the file is (somehow) shared among regions, I could see how that might be a problem, and the user should be fore-warned. Or is there a possibility of letting the user choose between that or creating a copy, reassigning the copy to the region that was selected and editing the copy. Perhaps that raises some other complications though, and I would let you speak to that. In at least a couple of instances, I found myself exiting Ardour, locating the .wav file in the "interchange/<proj>/audiofiles/" folder and editing it directly. That may be considered a no-no, but it worked nonetheless. Obviously, if the user changes the length or number of channels of the audiofile, then something will need to be decided about how Ardour deals with that when the external editor is finished. This raises another question: I'm sure Ardour is caching certain data about the file (e.g. peak data, analyses, etc), and it will have to somehow know that the external editor is finished so that the cache can be invalidated and things can be redrawn. One possibility is that for Ardour to check the timestamp on the file before assuming any cached info is still valid. Is it doing this already, or is that potentially a sweeping change through the code. I'd appreciate some pointers on the matter. Perhaps I can be talked out of trying to implement the change myself :). I'm rambling on to be sure. So, we can also take this discussion somewhere else if need-be, but the archive of the expanded info on your comments might be helpful. Thanks |
|
|
Okay, so I did some digging into the code and perhaps have a better understanding of the situation: The reason for your concern is that a region is made up of an audiofile per channel in the region. (e.g. it's "sources"). Is this correct? So, if the user were to want to edit a region in an external editor, either (1) the editor will have to understand that these (e.g. 2 for stereo) files are two channels of the same file, or (2) Ardour would need to stitch all the channels back together into a single file, open that in the external editor, and then separate the multi channel file back into the multiple files when the external editor is finished. Am I understanding your original comment correctly now? Assuming so: I don't suppose Ardour3 is planning to change directions and internally use multi-channel audio frames, is it? Though, I can image some reasons why this design decision was made originally. There's also something about "master_sources", but I can't see exactly how this relates to any functionality I've ever used. Are master sources relevant to the feature request? |
|
|
My use case will greatly benefit from this feature. We dub TV shows in Local Languages, and sometimes close micing is unavoidable due to recording environment constrains. To remove pops and clicks, we regularly need to export regions from Ardour, fix using Audacity's spectral editing tools, re-import back in Ardour and resync. Audacity's pitch shift and time stretch also work better for voice recordings. Other tools like Clip Fix and Click Removal come in handy too. The way this can be achieved is: With a mono or stereo Region selected: 1. set Range Selection from the selected region 2. bounce the Range without processing 3. open exported file in Audacity 4. user fixes/processes the file in Audacity and saves a new file. 5. back in Ardour, with the same range already selected, (a) user drops the fixed file back in place and manually syncs it OR (b) a new Replace Region feature is implemented in Ardour, which can essentially be the same function that is called when a Bounce Range or Consolidate Operation is executed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-03-19 15:11 | marukqs | New Issue | |
| 2004-03-19 15:11 | marukqs | => marukas@hardcore.lt | |
| 2004-03-19 15:11 | marukqs | Name | => Marijus Bernotas |
| 2004-05-26 12:44 | paul | Note Added: 0000852 | |
| 2004-05-26 12:44 | paul | Priority | normal => low |
| 2004-05-26 12:45 | paul | Status | new => acknowledged |
| 2007-02-14 21:45 | taybin | Note Added: 0003251 | |
| 2007-02-14 21:45 | taybin | Category | bugs => features |
| 2007-02-15 21:33 | taybin | Relationship added | has duplicate 0000345 |
| 2007-02-16 02:05 | timbyr | Relationship added | related to 0001483 |
| 2010-06-23 13:29 | cth103 | cost | => 0.00 |
| 2010-06-23 13:29 | cth103 | Target Version | => 3.X |
| 2011-07-17 06:18 | ddurham | Note Added: 0011148 | |
| 2011-07-18 04:18 | ddurham | Note Added: 0011155 | |
| 2012-03-20 11:15 | realhangman | Sponsorship Added | realhangman: US$ 50 |
| 2012-03-20 11:15 | realhangman | Sponsorship Total | 0 => 50 |
| 2024-03-25 07:47 | gaurangarora | Note Added: 0028616 |
