View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006793 | ardour | bugs | public | 2016-02-26 13:33 | 2020-04-19 20:17 |
| Reporter | silvermonk | Assigned To | timbyr | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | GNU/Linux | OS | Arch Linux | OS Version | 20160225 |
| Fixed in Version | 5.X git (version in description) | ||||
| Summary | 0006793: After Tempo Change MIDI Notes drift when moving or resizing region | ||||
| Description | After Tempo Change MIDI Notes drift when moving or resizing region. Had this with the package in the Arch Linux User Repo, built it myself from the TRUNK to see if the issue was related to the Arch build. This is Ardour 4.7.227 "Cluster and Eno" (built from revision 4.7-227-g99b9fc6) Intel 64-bit It has exactly the same issue. | ||||
| Steps To Reproduce | Tempo set to 72 BPM Record some MIDI Duplicate it once Unlink it from Other copies (at this point, it behaves normally ; moving it yields no surprises). insert a new tempo at the end of the original = start of the copy, set a different tempo than the one that was in use when the region was recorded (I used 120). When moving or resizing the copy, the notes appear to shift around unpredictably, both when moving and resizing. It is near to impossible to get the notes aligned with the start of the region again. | ||||
| Additional Information | movie: http://apsu.be/tempo_change_note_shift.webm attached: project files. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
[ERROR]: MidiTimeAxisView: unknown automation child |
|
|
I have just run into this myself. According to Help|About I am running Ardour 4.5.3 (built from revision 4.5-3-gcf6a3af), although the Fedora package I am using is tagged as 4.6.0-1.fc23. Changing the new tempo mark back to the original tempo (so that there is only one tempo in the piece) caused regions to behave correctly again. My guess is that the region is being timescaled according to the first tempo marker, which causes it to skew when mapped against the tempo area that it's in, if that makes any sense. |
|
|
Could you please try this with a nightly build? Many changes have recently happened in this area. Thanks |
|
|
I just tested this with a build of master@b2aaffad (nightly >= 5.4.399) and can not reproduce this issue. Marking issue as resolved. |
|
|
Issue has been closed automatically, by Trigger Close Plugin. Feel free to re-open with additional information if you think the issue is not resolved. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-02-26 13:33 | silvermonk | New Issue | |
| 2016-02-26 13:33 | silvermonk | File Added: tempodemo.tar.bz2 | |
| 2016-02-26 13:40 | silvermonk | Note Added: 0018015 | |
| 2016-05-23 03:06 | agittins | Note Added: 0018217 | |
| 2016-06-02 14:16 | nick_m | Note Added: 0018228 | |
| 2016-11-20 00:54 | timbyr | Note Added: 0018996 | |
| 2016-11-20 00:55 | timbyr | Status | new => resolved |
| 2016-11-20 00:55 | timbyr | Fixed in Version | => 5.X git (version in description) |
| 2016-11-20 00:55 | timbyr | Resolution | open => fixed |
| 2016-11-20 00:55 | timbyr | Assigned To | => timbyr |
| 2020-04-19 20:17 | system | Note Added: 0023593 | |
| 2020-04-19 20:17 | system | Status | resolved => closed |
