MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007157ardourbugspublic2016-12-03 07:032017-02-17 13:10
Reportermk1967 
Assigned Topaul 
PrioritynormalSeverityminorReproducibilityalways
StatusassignedResolutionopen 
PlatformLinuxOSDebianOS Version8
Product Version5.5 
Target VersionFixed in Version 
Summary0007157: Cannot move an automation curve together with a region
DescriptionAfter having made fade automation curves I move a region where I have made one of such curves. I can move the region but the curve stays where it was (though I had set the option "move automation curves with regions").
Steps To Reproduce- setting up a project
- importing a *.wav file (or some of them) and placing them on one or more tracks
- producing fader automation curves (either with mouse or with Mackie MCU Pro, in "Write" or "Touch" mode)
- grabbing a region (where a curve is) with mouse and moving it backwards or forwards on the track
- the region can be moved
- the curve stays where it is, cannot be moved
Additional InformationSame problem already in Ardour 5.4 and 5.3. NOT in Ardour 5.0.

Same problem when working on new AVLinux 2016, UbuntuStudio 14.04, and LibraZIK (http://librazik.tuxfamily.org/ [^]).
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0019268)
stadeltobi (reporter)
2017-01-06 07:13

This bit me as well - not sure if it helps, but I bisected it down to this commit:

commit 172bcc816504a08eb1bccbb72f58d7db7a8cb7e4
Author: nick_m <mainsbridge@gmail.com>
Date: Sat Aug 13 04:02:46 2016 +1000

    Audio-locked midi region fixes.
    
        - don't alter region frame length on tempo change or position change.
    
        - set region _start correctly (see comments) on tempo map change.
    
        - ensure audio-locked region's beat is set on tempo map change


Let me know if I can help in any other way.
(0019272)
stadeltobi (reporter)
2017-01-06 09:20

Okay, so since I had to kill some time on the train anyway, I couldn't resist to dig a little deeper.

It does seem indeed relate to the commit pointed out above: I reverted the commit on top of 5.3 (which showed the same issue), and that fixed it. The patch doesn't revert cleanly on 5.5 any more, and while resolving that seemed obvious enough, I was a lazy bum ;)

More specifically, the problem seems to be the removal of the

  if (position_lock_style() == MusicTime)

statement around
   
   p_and_l.add (Properties::length);

in region.cc in this commit that triggers it. When I reintroduce that statement on top of 5.5, the problem goes away for me.

Of course this is a bit of a shot in the dark, since I don't know what the commit in question intended to do in the first place (I don't use midi tracks myself), so I haven't checked at all whether this re-introduces _another_ issue that the original commit intended to fix, but I thought the info might be helpful anyway.

In other words, applying this:

diff --git a/libs/ardour/region.cc b/libs/ardour/region.cc
index 0d0a40d..e1fb2de 100644
--- a/libs/ardour/region.cc
+++ b/libs/ardour/region.cc
@@ -611,7 +611,9 @@ Region::set_position (framepos_t pos, int32_t sub_num)
           Notify a length change regardless (its more efficient for MidiRegions),
           and when Region has a _length_beats we will need it here anyway).
        */
- p_and_l.add (Properties::length);
+ if (position_lock_style() == MusicTime) {
+ p_and_l.add (Properties::length);
+ }
 
        send_change (p_and_l);
 

...on top of 5.5 makes the issue go away for me.

Again, let me know if I can help some more.
(0019298)
paul (administrator)
2017-01-22 13:20

Your change makes sense at some level: only MIDI regions will potentially change length by changing their position.

But I'd like to get an undestanding of why the change (unconditionally claiming that the length changed in addition to position) caused breakage, because I think the best fix may be a little different from this.
(0019364)
mk1967 (reporter)
2017-02-11 15:42

Thank you VERY much for having solved it in Ardour 5.6 ! Glad to see and work with it :-).
(0019409)
stadeltobi (reporter)
2017-02-17 13:10

Hah. Indeed, I can verify that this is fixed in 5.6. Not sure what actually did it (I have a strong suspicion it's 59daffea1d by nick_m) - but either way, @paul, I guess this one can be closed.

Awesome. You guys rock.

- Issue History
Date Modified Username Field Change
2016-12-03 07:03 mk1967 New Issue
2017-01-06 07:13 stadeltobi Note Added: 0019268
2017-01-06 09:20 stadeltobi Note Added: 0019272
2017-01-22 13:20 paul Note Added: 0019298
2017-02-07 08:46 paul Assigned To => paul
2017-02-07 08:46 paul Status new => assigned
2017-02-11 15:42 mk1967 Note Added: 0019364
2017-02-17 13:10 stadeltobi Note Added: 0019409


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker