MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006793ardourbugspublic2016-02-26 05:332016-11-19 16:55
Reportersilvermonk 
Assigned Totimbyr 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformGNU/LinuxOSArch LinuxOS Version20160225
Product Version 
Target VersionFixed 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: http://apsu.be/tempo_change_note_shift.webm [^]
attached: project files.
TagsNo tags attached.
Attached Filesbz2 file icon tempodemo.tar.bz2 [^] (13,560 bytes) 2016-02-26 05:33

- Relationships

-  Notes
(0018015)
silvermonk (reporter)
2016-02-26 05:40

[ERROR]: MidiTimeAxisView: unknown automation child
(0018217)
agittins (reporter)
2016-05-22 20:06

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.
(0018228)
nick_m (reporter)
2016-06-02 07:16

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

Thanks
(0018996)
timbyr (developer)
2016-11-19 16:54

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 History
Date Modified Username Field Change
2016-02-26 05:33 silvermonk New Issue
2016-02-26 05:33 silvermonk File Added: tempodemo.tar.bz2
2016-02-26 05:40 silvermonk Note Added: 0018015
2016-05-22 20:06 agittins Note Added: 0018217
2016-06-02 07:16 nick_m Note Added: 0018228
2016-11-19 16:54 timbyr Note Added: 0018996
2016-11-19 16:55 timbyr Status new => resolved
2016-11-19 16:55 timbyr Fixed in Version => 5.X git (version in description)
2016-11-19 16:55 timbyr Resolution open => fixed
2016-11-19 16:55 timbyr Assigned To => timbyr


Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker