View Issue Details

IDProjectCategoryView StatusLast Update
0007157ardourbugspublic2017-02-17 21:10
Reportermk1967 Assigned Topaul  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
PlatformLinuxOSDebianOS Version8
Product Version5.5 
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.

Activities

stadeltobi

2017-01-06 15:13

reporter   ~0019268

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.

stadeltobi

2017-01-06 17:20

reporter   ~0019272

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.

paul

2017-01-22 21:20

administrator   ~0019298

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.

mk1967

2017-02-11 23:42

reporter   ~0019364

Thank you VERY much for having solved it in Ardour 5.6 ! Glad to see and work with it :-).

stadeltobi

2017-02-17 21:10

reporter   ~0019409

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 15:03 mk1967 New Issue
2017-01-06 15:13 stadeltobi Note Added: 0019268
2017-01-06 17:20 stadeltobi Note Added: 0019272
2017-01-22 21:20 paul Note Added: 0019298
2017-02-07 16:46 paul Assigned To => paul
2017-02-07 16:46 paul Status new => assigned
2017-02-11 23:42 mk1967 Note Added: 0019364
2017-02-17 21:10 stadeltobi Note Added: 0019409