View Issue Details

IDCategoryLast Update
0006793bugs2020-04-19 20:17
ReportersilvermonkAssigned Totimbyr 
Status closedResolutionfixed 
PlatformGNU/LinuxOSArch LinuxOS Version20160225
Product Version 
Fixed in Version5.X git (version in description) 
Summary0006793: After Tempo Change MIDI Notes drift when moving or resizing region
DescriptionAfter 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 ReproduceTempo 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 Informationmovie:
attached: project files.
TagsNo tags attached.



2016-02-26 13:33


tempodemo.tar.bz2 (13,560 bytes)


2016-02-26 13:40

reporter   ~0018015

[ERROR]: MidiTimeAxisView: unknown automation child


2016-05-23 03:06

reporter   ~0018217

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.


2016-06-02 14:16

reporter   ~0018228

Could you please try this with a nightly build?
Many changes have recently happened in this area.



2016-11-20 00:54

developer   ~0018996

I just tested this with a build of master@b2aaffad (nightly >= 5.4.399) and can not reproduce this issue.

Marking issue as resolved.


2020-04-19 20:17

developer   ~0023593

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.

Issue History

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