View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007157 | ardour | bugs | public | 2016-12-03 15:03 | 2017-02-17 21:10 |
| Reporter | mk1967 | Assigned To | paul | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Platform | Linux | OS | Debian | OS Version | 8 |
| Product Version | 5.5 | ||||
| Summary | 0007157: Cannot move an automation curve together with a region | ||||
| Description | After 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 Information | Same 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/). | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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. |
|
|
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. |
|
|
Thank you VERY much for having solved it in Ardour 5.6 ! Glad to see and work with it :-). |
|
|
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. |
| 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 |
