Allow Range Markers to be bound to Region Start and End

Here are some basic rules that would follow for bound range markers:

  • Allow a pre-gap and post gap for start marker (editable in Locations window)
  • Allow a pre-gap for end marker (editable in Locations window)
  • Can be outside the range
  • Cannot be inside the range.
  • Edits to a range marker length (including gaps), move all following ranges and markers.
  • Markers can be bound and unbound.
  • Changing the length of a region with its bound markers also appropriately moves all regions and bound markers.
  • Deleting a region also deletes the markers bound to it and moves all other regions appropriately.
  • Behavior is the same regardless what track the region is on.
  • Marker and bound region order can be changed by editing values in the Locations Window.
  • Bound region order can be changed with the <ctrl+arrow> keys (like changing track order).
  • Bound range markers cannot overlap.

Use Case 1:
During mastering, a client wants an extra second between the first and second song. The engineer then adds one second to the pre-gap of the start marker for song two. By doing this, the region and the marker is moved to the right by one second. All following regions and markers also are moved. One second may also be added to the project length.

Use Case 2:
During mastering, the first song is shortened by a few seconds (client decided to fade out earlier). By simply trimming the region by two seconds off the end, all following regions and markers are moved to the left by two seconds. The length of the project is shorten by two seconds.

Use Case 3:
A song is removed from the project by deleting a region with bound markers. The engineer simply selects and deletes the region and all other regions and bound markers are moved appropriately.

Use Case 4.
Client wants to switch the order of songs four and five. The engineer simply reorders the bound markers in the Locations window.

Please excuse my ignorance, if this feature already exists or is already in Ardour 3.


Feature Requests need to be put in Mantis (Issue Tracker link above) so that they are not lost. Thanks.



What is this forum for (“Ideas for Ardour”), if not for discussing potential new features?

Perhaps what you meant to say is, “That’s a fantastic idea, and one that is very well thought out! I think you should file it as a feature request in Mantis so it doesn’t get lost.”

In which case, I agree.


Whether or not I think it is a fantastic idea, it should still go into Mantis;) I am not saying discussion can’t happen here, but that it should be filed in Mantis.


For the record, I will say I think this starts falling apart when dealing with multiple regions in a range, but I don’t have time to type out a full reply right now. I think the basic concept has some merit, but the described implementation is not complete enough to go in as is:) My earlier point about feature requests in Mantis still stands of course.