View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002731 | ardour | bugs | public | 2009-06-15 08:38 | 2010-04-24 10:31 |
| Reporter | thorgal | Assigned To | paul | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | SVN/2.0-ongoing | ||||
| Summary | 0002731: Region reversal: some comments and design change proposal | ||||
| Description | As discussed with Paul on IRC, you should consider the following, code-wide (I am talking at a high level design, this is neither a patch nor code details): - a region (class) shall have a field "reverse of". - This field shall be NULL when the region is created (instantiated) - this field shall point to the region it originates from when reversing the region as reversing the region creates in fact a new region. This special creation shall therefore be tagged thanks to this new field. - if re-reversing the reversed region, we should get back to the original region without any creation. Of course, there are details and corner cases to be careful with. But I am proposing this small design enhancement because if you try to reverse a region again and again, your region list will blow up with clones of the original and first reverse regions :D The reverse operation here is 2pi symmetric. There is no need to create region clones. From my standpoint, I see it as a bug, even though minor. Feel free to change it to knew feature or tweak if think it more appropriate. As a side note, it may also help working around an issue reported earlier, namely time stretching or pitch shifting is badly affected and often dysfunctional when applied to a reversed region. The work around would be to time-stretch or pitch-shift the original region under the hood and reverse the result before being displayed (the time-stretched or pitch-shifted region would then be deleted at the end of this operation so the final result would appear like an original region, not the reverse of something else). The user would not see any of that :D I hope my description is clear by the way ... | ||||
| Tags | No tags attached. | ||||
|
|
Sorry for the typos, was in a hurry when I wrote this: - code-wide must be read code-wise |
|
|
i think this is not a realy good idea. because the order of processing is sometimes not unimportant and this would add a special case. the bug you refere to should anyway be solfed. |
|
|
create a region, reverse it, re-reverse it. Why would you create a clone of the very first region as a result ? |
|
|
ok in this case you are right. i thought you whant the order of processing be changed like: you do: reverse transpose changed to: transpose reverse in a way that reverse is always the last process but dont like this i can imagin processes where this would make a difference. |
|
|
I agree that if the processing order influences the result, we have an issue. There are 2 issues that are overlapping here: 1- region creation for nothing when double-reversing 2- problem when time-stretching or pitch-shifting a reversed region Issue 1 is to my mind a lower priority issue than 2. The ongoing design discussion we are having now would fix 1- and could be used as a workaround for 2- But I don't have enough knowledge of the internals of ardour, rubberband or sndfile to know whether the proposed design change would introduce unexpected side-effects due to the processing order. Conclusion: let's fix 2 one way or another, this is really bugging me. Getting these "error blabla tempoize blabla" messages, or worse, an ardour crash, is a PITA. What I end up doing to be able to move on is to export the region, use rubberband from the command line, import the new audio file into ardour. So this suggests to me that ardour is not using the rubberband lib correctly. But I can think of other spots where this could go wrong as well. The problem is: I don't have time to dig this further and be more helpful. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-06-15 08:38 | thorgal | New Issue | |
| 2009-06-15 09:01 | thorgal | Note Added: 0006125 | |
| 2009-09-03 09:13 | olaf | Note Added: 0006634 | |
| 2009-09-04 08:47 | thorgal | Note Added: 0006642 | |
| 2009-09-04 10:14 | olaf | Note Added: 0006643 | |
| 2009-09-04 10:49 | thorgal | Note Added: 0006644 | |
| 2009-10-31 14:51 | paul | Status | new => assigned |
| 2009-10-31 14:51 | paul | Assigned To | => paul |
| 2010-04-24 10:28 | cth103 | Category | bugs => bugs2 |
| 2010-04-24 10:31 | cth103 | Category | bugs2 => bugs |
