Join two regions

I’m using the same version as you do, Ardour 5.12.0, from KX Studio (on Linux Mint).
I don’t think it’s because of quantization or unquantized area, because in the first example, I’ve entered all the notes with mouse and snapping. This behavior also affects when you export midi, the resulting file is sometimes unpredictable.

I’ve tried Ardour 6 on raspberry pi, and it seems you can’t consolidate midi at all, it just doesn’t do anything.

I agree with you. I’m also used to Ardour for recording audio, and it works perfectly!

Yes, Ardour 6 is too raw to test as I know (alpha stage). Sometimes MIDI regions are not even moving at all.))

I’ve found range consolidation works until you have a tempo change to the left of the range. Then it exhibits the strange shrinking behavior described.

1 Like

Consolidate range works ok. In the Grab/Select mode it would be nice to add “Glue” - only for joining selected regions as they are

1 Like

We will never offer a “Glue” operation that is any different than “Consolidate”.

In the example in your screenshot, the two regions correspond to entirely different MIDI files. Creating regions that can be edited but are built of multiple files is a nightmare. We do it for audio, because you cannot edit the contents of audio regions.

There is a case for a “consolidate” style action (i.e. write the MIDI data to a new file, replace the selection with a single region) that is simply to access and works for selected regions (only; no time selection).

1 Like

@andrzejwawer, @paul

Consolidate several regions in “G”-mode could be good edition to the functionality.

Fiew thoughts are going to mind:

  • when we try to consolidate regions standing separately (in “G”-mode) - the gap between the regions must be as an empty area in the new consolidated region;
  • a “Glue” function can be understood as a “Consolidate” (I mean “Glue” is to make an unbroken file - suppose it’s a lexical terminology thing what we “mean”);
  • the “Consolidate with the deleting source midi files” feature - could be having a name “Glue”

The third point (in the list above) could let us select few regions in a track in “G”-mode and make an entire one (superfast with some shortcut may be).

Nonsense. If the user can do something, the computer should be able to do it too. If the user can ACHIEVE combining MIDI regions in a roundabout way involving several manual steps, then “Combine” operation CAN be implemented for MIDI by AUTOMATING THE EXACT SAME STEPS and executing them transparently to the user. It CAN be implemented. It just ISN’T.

1 Like

I might suggest you read the entire thread before posting a response, especially to a comment from 3+ years ago that can easily be out of date in that timeframe. You are arguing something that has already been accepted.

For the record there is a big difference in these two actions described, even though they may look similar from a user standpoint. One involved multiple different sources/files/etc. combined in a way that allows, for instance a midi note to start in one file, and end in another, and still work. THAT is incredibly difficult to do right, and might be argued as foolish, and is what Paul was responding to in what you quoted.

The other is to write the MIDI data from multiple sources into a single file, and THEN display that file so that it can be edited, which doesn’t involve the situation above, and as Paul already commented, is something that is more possible. This by the way is what the user can do in a roundabout way, and seems to be what you are arguing for.


To follow up on what Seablade said:

The whole point of the “Combine” operation for audio is that it DOES NOT write any audio data to disk, it just plays games with the metadata to accomplish the goal. This is relatively easy for audio because there is no way for the user to subsequently edit the contents of the combined region (you can move it around and truncate it and all the usual non-destructive operations that a DAW allows, but you cannot change the contents of the file on disk). This is not true for MIDI, where being able to edit the contents of the region (and thus change what is on disk) is part of the normal workflow.

Consolidate/Bounce do write new data to disk, and they are available for audio and MIDI. These mirror what a “user would do” by writing the data to disk in a new file, and creating a new region from the result.

I don’t know if you’re a native english speaker, but “This is nonsense” is quite aggressive, especially when directed at a person who actually wrote the software.


Hello everyone. I had wondered about the glue midi option, however it’s not a deal breaker for me. What I am doing more often now is recording the midi synth straight to disk which is luxury I didn’t have when I started out with Steinberg Pro 24. Compared to other dates, I think Ardour handles live instruments best. Different emphasis that’s all.

Dates DAW auto correct…

As a user, I don’t care that regions are represented as separate files on disk. That is a storage implementation detail I shouldn’t even be hearing from you about. You are basically using disk-backed containers in your program. You allocate them when necessary, destroy them when necessary, and split them when necessary. Why not also merge them when necessary, without even telling the user that in the steaming internals of your region store you are deleting two files and writing one?

I am not a native English speaker, but I said “nonsense” with full awareness of the word’s tonal quality, because it really is nonsense, and the fact that this nonsense is coming from the author of the software makes things even worse.


There are several reasons for there being two different operations, If you focus on audio files being relatively small, then there may be no apparent reason not to “delete two files and write one”. But Ardour (and DAWs in general) are not intended to handle only the trivial cases. First of all, Ardour (like almost all DAWs) is a non-destructive editor, which means that it never destroys data on disk unless explicitly told to do so by the user. Consequently, you cannot delete two files as part of another operation - that sort of thing can happen only during an explicit “cleanup” operation in which files no longer being used are removed with the explicit consent of the user. Secondly, the files could be extremely large. GB’s of data. Merging them into a new file, even on very fast NVME storage device can take several seconds. This is not an operation you just do in the background.

Consequently, Ardour has two distinct operations which result in similar things for the user, but with radically different implications for the state of your computer system.

Combine performs a trick with metadata that creates a single region from any number of existing regions. Nothing on disk changes.

Consolidate writes 1 more new files to disk, and creates a new region based on the new file. No existing files are removed from disk.

This is a rather sheltered perspective. You might not want to care about disk storage, but you do care about the DAW being (a) non-destructive (b) sane in its use of storage resources (c) capable of being backed up (d) capable of some level analysis if/when things go wrong. All of these things connect with the concept of “files on disk”, an unfashionable concept among a generation or two raised on computing platforms that hide this abstraction, but I am extremely confident will return to fashion within a finite number of years.

In the DAW space, even the simple act of wanting to move a session to different platform requires grappling with files. If you completely hide the implementation, every such move requires an export in order to create files that can be moved - again, with trivial sessions perhaps not an issue, but in the general case, an extremely undesirable property. In Ardour, if you need to access the underlying data for a session it’s all in $DIR/session-name/interchange, as every day, regular old files.

You’ve also inverted the relationship that most people (I claim) have with regions. Regions are not represented as files. Files are represented as regions, in almost every case. Operations like “Combine” are infrequently used. Regions are a way of manipulating, visualizing, and generally use the data stored in files, and for many people, the files have their own distinct identity, typically connected with how the file was created. If it’s a sample of a kick drum obtained from some sample library source or a friend, then the conceptual mapping between that file and that sound, a mapping that exists outside the DAW as well as inside of it, is important to a lot of people. If it’s a recording of a performance on an instrument, again, the mapping between “this file contains that performance” is something that I strongly believe that all but the most mobile-app-shaped users will want to be able to sense is respected by the DAW.

So yes, it’s quite fashionable these days to pretend that files are irrelevant, that users don’t need to know about them, that users are confused by even the concept. The final claim may be true, but should not be. We will continue to insite that the concept of a file matters, that the mapping between files and sounds matters, and that the correct mental model is that regions represent files, not the other way around.


Users are not “confused” by the concept of a file. Users are hampered by having to dance around a limitation that exists in the MIDI composing workflow because other workflows are primarily based on a 1:1 correspondence between files and things that can be manipulated in the program - a correspondence that is irrelevant to the MIDI composing workflow. You are not importing or exchanging musical notes, you are drawing or keying them in with your shaky hand! The musical content is the precious thing here, not how it is stored. You should be able to just edit your track without having your flow interrupted e.g. by the requirement to suddenly come up with a new filename for something that resulted from an elementary editing operation and you immediately intend to continue modifying it.

It is possible to split MIDI regions in Ardour as an elementary editing operation, without being distracted by realities of storage. Why not the other way?

1 Like

Sorry, but confusion about files has been well-documented among younger generations. For example: Kids who grew up with search engines could change STEM education forever - The Verge

Maybe you’re not importing or exchanging musical notes, other people are.

Until something causes you to need to know (and maybe change) how it is stored.

Joining two regions is not an elementary editing operation. Copy-n-paste MIDI from one region into another is an elementary editing operation, and that works as expected. Joining regions is at least one step further into complex editing.

I would expect that there could be an operation easily written which effectively pastes the later region into the first region, then deletes the second region, which would give you what you want.

As mentioned and discussed above, the combine operation as implemented for audio (playing with metadata) is never going to be implementable for MIDI.

When they are, they are. When they aren’t, they aren’t. It depends strictly on what is being done, not on who is doing or what their paradigms and thinking habits are, or which age cohort they belong to.


Yes, please!

1 Like

Hi! I have solved it this way:

With RANGE MODE selected, you drag all over the N regions you have to select them, then you right click on one of them and click CONSOLIDATE.
That is all.

Greetings from Montevideo, Uruguay…and thank you very much to all of you!!

When we select desired regions in G-mode,
as a variant,
may be this could be possible to implement a LUA script to join 3 steps:

1. Set Range to Selected Regions
2. Consolidate Range
3. Set the mouse mode back to G-mode (Grab mode):


and add it to the script’s knobs with some kind of icon:

This script could work as “Glue” function in G-mouse-mode without any necessity to switch to the Range-mouse-mode&back to G-mouse mode.
Only one drawback of this script - if we select some distant regions and set the selection to Range - this includes all the regions between selected and consolidate all of them. In ideal goal - this could be super if we could Glue only the separate selected regions an make an empty area in the result consolidation at that places where the unselected regions were.
I don’n know LUA\\)

1 Like

Come here people:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.