Revisiting classical editing and mixing

mkindred · March 1, 2026, 11:26pm

I’ve been brainstorming my eventual workflow for editing and mixing classical music (multi-track, multi-take) in Ardour.

I know this overall subject has been covered before, but I wanted to see if anything has changed in the last five years that might affect my editing flow.

At this point, I envision that my workflow will roughly be (assuming editing before mixing):

import all tracks, and combine them into a ‘source’ group
duplicate all these tracks without playlists (empty), and combine these into an ‘edit’ group
copy/paste the best take from 'source’to ‘edit’
fake the 4-point edits by splitting the ‘edit’ tracks, and copy/paste a section from an alternate take from ‘source’.

The part of the process that seems tedious is that all the takes are distributed across the timeline horizontally, rather than being readily available in track groups vertically like Reaper/Cohler. (https://www.youtube.com/watch?v=KOcHlpNeTkY) So I’ll be doing more copying/pasting from different points in the timeline, and unless I’m missing something, auditioning will be a bit more difficult.

I’m curious whether this overall approach matches how others edit/mix, and whether I might be missing something crucial that’d simplify auditioning and editing.

I’ve documented my basic workflow here https://www.youtube.com/watch?v=d1ihYBHM9H4

GhostsonAcid · March 2, 2026, 10:14pm

I watched both of those videos, and it’s all certainly interesting…

“Cohler Classical” is obviously well thought-out and highly custom-tailored for editing classical music it seems, yes. (~Hence why it costs $125. )

But I see no reason why most of the functionality it includes couldn’t be incorporated into Ardour as well.

…
How much coding experience do you have?
And do you know about (or use) Lua scripts in Ardour perchance?

Because I think it would likely be possible to create a custom script to do this “4-point editing”, as it’s called. …

…
Hmm…
I was typing-up a possible idea for doing that with Lua, but realized there’s actually quite a lot of steps necessary in this… potentially. So I’m going to have to think about this another day or so and consider what it might take…

As for other things I’ve considered (and tested), and which I’ll have to consider more:

• Maybe stacking all regions (of the exact same take/performance) onto single tracks, instead of having them across multiple tracks. -Would save screen space for initial editing.
• Maybe even using Ardour’s region Combine option for even further, initial simplification. -To which you’d then use Uncombine later on when you wanted to split-up everything (all the different mic recordings) for further mixing… which leads me to…

→ The one big drawback here, though (potentially), is that if you want to mix the final, composite version of the music piece, it might be easier to have all the various mic recordings across several tracks (-just as you currently do, as in your video). That way panning of certain mics is easier, adding plugins, riding the fader up and down for certain mic recordings during different portions, etc…

…
~Just some initial ideas and food for thought.
I’ll probably comment a bit more later…

-J

mkindred · March 3, 2026, 12:22am

I’m not familiar with combining regions. I’ll take a look and see if it makes editing easier.

But that did give me an idea. I could:

do a basic mix (levels, panning)
bounce to a single stereo track
edit the stereo mix track
invoke a lua script that replicates all the cuts/fades from the stereo mix to the other tracks
finish mix

Step 3 could be conventional copy/paste edits or, with a lua script as you mentioned, actual 3- and 4-point edits. Regardless, it’d be easier to audition and manage the edits.

I’m guessing that the script for step 4 wouldn’t be difficult.

I do write code, and learning lua has been on my to-do list for a while.

Thanks for the suggestions.

GhostsonAcid · March 4, 2026, 9:08pm

Yo,

I’m terribly sorry for the length of this post… O___o

I’ve thought about this on-and-off over the past few days, actually. And I’m thinking I might try to write a script or two to get this “4-point editing” business off the ground in Ardour 'cause… why not?

But first…

Unless I’m misunderstanding you here, that would probably be very complicated to achieve. However, my copy-paste script AudioClipboard can indeed swap sources (i.e. copy some regions, but paste using other sources, thus preserving all the original fades, envelope, etc.), but in your situation you’re talking about trying to ‘de-bounce’ (so to speak) a series of regions pointing to who knows how many different takes/recordings/sources… O___o … It just seems like a nightmare waiting to happen, having to go back and split everything back up in order to finish the mix.

So…
I’d suggest working with either:
• Groups of tracks, as you currently do.
• Or combined regions (which you can then uncombine later).

…Each of those options still comes with its own set of pros and cons though. (And so perhaps there’s another option we haven’t thought of yet…? )

~And now for the fun part(!), about a potential Lua scripting solution…

For initial simplicity (and so to ignore groups of tracks for the time being), the goal here might be to swap region “A” with region “B”:

…
As I considered how to do this, it seemed best to have two Lua scripts to make this happen.

Obviously it would be slightly more convenient to (in one simple flow like this) select A, then B, then hit a button (or key-command) to execute a single script that would immediately swap them. But simultaneously selecting A and B like this when, down the road, A and B are strewn amongst multiple tracks (as in your multi-mic recordings), would be at best incredibly tedious, as you’d have to hold-down cmd/ctrl and click region after region to select all constituents of A and then B. … Also, I don’t even know if Lua could differentiate between the regions first selected (A), and the regions selected last (B), etc…

All in all, there’s many possible roadblocks here. So again, I think two separate scripts to clearly differentiate between the ‘establish this as the destination region/range’ phase, and the ‘use this new region/range’ phase would be best, and thus 4 clicks for a swap, like so:

Click to select region A, or click and drag to select a range to define A.
Click (or use a key-command) to execute script #1, which would:
• If a range was selected, our script would automatically use the Ardour function “Separate” to create a distinct region.
• Save A’s track’s name(/etc.), start of region A, and A’s unique ID onto a temporary file in the computer’s /tmp/ directory (or similar).
Click to select region B, or click and drag to select a range to define B.
Click (or use a key-command) to execute script #2, which would (in this order or some other sequence, etc.):
• If a range was selected, use “Separate” to create a distinct region (B).
• Save (in a temporary Lua table) B’s unique ID, and starting position.
• Erase B.
• Read our temporary file in /tmp/ for data on A.
• Duplicate A (using its ID) in B’s former position based on when B had started on the timeline.
• Find and erase A.
• Duplicate B (using its ID) in A’s former position based on when A had started on the timeline.
• Finally, overwrite B’s info (namely its ID) onto our temporary, external /tmp/ file. (This way our current destination range/area remains the same, and a further selection of a region C, say, could then be followed merely by script #2, and B would be swapped for C, and so on… -Would be convenient for inserting different takes into A’s original position, one after another, with at most 2 clicks for each new swap.)

…
Now, just to be clear, I decided to go with the idea of swapping takes because I don’t think it’s wise to delete A, or B, or C, etc., from the timeline. → All possible versions should be available to the editor until they decide to delete them. …But I’m curious now what your thoughts are, @mkindred? ~I would love to continue getting your feedback and ideas on what you think might be the best approach here, seeing as you’re the OP.

…
Even if I began making something along these lines, it unfortunately would only get us started, as expanding the script to work across multiple tracks of regions (potentially) would probably get modestly more complex. … And none of this even addresses convenient cross-fading handling (obviously), or what if A and/or B are composed of multiple regions horizontally, the effects of Slide vs Ripple mode, how to ensure horizontal space is automatically shrunk or expanded to accommodate a new region, how any potential underlying automation might be destroyed, etc., etc… o_____o

…
But for now, this is good enough ‘thought for food’.

Cheers!
-J

mkindred · March 5, 2026, 6:44pm

Because of how much simpler life would be editing a single stereo track, I had already constrained my thinking along those lines. Given that approach, then the complexity of each step of editing is vastly simplified.

(This post might answer the question about how complicated my proposed lua script would be, or it might show my lack of knowledge about the relationships between source, region, and playlist.)

Let’s say I have 10 mono mic channels. I’d begin ensuring that each track (one per mic) would have a single source/region of the same length. If that weren’t the case, then I’d bounce them 1:1 to get that starting point.

I’d then do a basic level/pan mix and bounce that to a single stereo track. At that point, I’d have 11 tracks (one per mic, plus a single rough 2-mix) with the exact same length, each with a single region/source. I could then cut up the 2-mix into the appropriate takes to make editing easier.

If I were then to copy/paste sections from the 2-mix to a new ‘edit’ track, regardless of the edit process (actual 4-point edits or just copy/paste/adjust), I’d have a single edited track that draws from a single source.

At that point, couldn’t I have a single lua script that’d duplicate the edited 2-mix one time for each mic track, and then replace the source for each from 2-mix to individual mic?

GhostsonAcid · March 6, 2026, 9:04am

I understand you very clearly now, and your idea here is not necessarily terrible.

Yes, but there is no Ardour-Lua, built-in mechanism to 'copy this region/source but paste using this other source', or 'copy only this region's 'surface attributes' (like position, trim, fading, envelope, etc.), and then when I invoke paste later use this other source', etc…

This is why that step would be very difficult to figure-out, in my opinion.

And this is why with AudioClipboard I had to develop my own, independent mechanism for copying and pasting in Ardour (-which by the way has been incredibly reliable at recreating 1:1 regions/attributes across the months I’ve been using it).

For now, manual source-swapping is possible, but would be tedious in your case as you’d have to repeat this same process 10 times, once per mic/track (-image taken from my GitHub page):

(FYI: I already actually do this for drum tracks. I.E., I’ll sometimes have a full stereo drum mix edited, but then I’ll want to pass those edits down to the snare, the kick drum, etc… ~And so I use that feature (once per track) to ‘share’ those edits. Again, tedious, but does in fact work.)

But to remove the tediousness of it, in theory I could reorganize and amend AudioClipboard’s code to create a loop to automatically do this step x-number of times over x-number of final source files across x-number of specific tracks. … But that is WAY easier said then done.

So at this point, yes, you could try the exact workflow you describe, and you don’t even need to do any Lua scripting as AudioClipboard can already do the final, source-swapping for you. It might be tedious, but at least you’d only have to do it once, towards the end of that editing step. Feel free experiment with AudioClipboard to see if it might work for this. (-Also note that AudioClipboard will not re-import any source file you redirect to that’s already present/imported/embedded in your project, and that’s also visible/present somewhere on the timeline.)

…
But here’s where I really thought the whole thing might potentially explode in complexity:

Um, couldn’t you potentially have different/multiple sets of 11-track groups to work with? In that Cohler Classical demo video, for example (-as well as other videos on 4-point editing I’ve now seen), they had multiple takes -and thus multiple track groups- of the same song(/etc.) they were working with.

So, in that type of situation, you might have 11-track-groups A, B, C, and so on… -and then your main edit ends-up being composed of a little bit of A, B, C, etc…

This seems like a reasonable and likely situation to find yourself in, no? … Although to avoid this, I suppose you could first bounce all potential takes into an “A” group, so you’re literally working with just 1(+10) tracks? Hmm… Possible, but irritating to have to set up.

Cheers,
-J

…
[EDIT: Here’s a video example of the “Manually Select Files To Use” feature that I made a few weeks ago; it gives a rough idea of what this feature is capable of: AudioClipboard - Manually Select Files To Use - Demo 1 ]

mkindred · March 7, 2026, 6:46pm

Yeah, I was thinking that I’d place all takes horizontally in the same tracks initially. I think that dicing tracks (one per mic) from a single region into takes would be pretty quick work, though. (Granted, all this still assumes that I can do source swapping at some point later in the process. If not, ugh.)

The number of takes is going to impact the best workflow. Working with 4 takes is a very different organizational animal than working with 20.

I think I’ll try my hand at writing a few scripts to see the process and what’s available to me.

mkindred · March 8, 2026, 3:53pm

I finally got around to spending a little time with AudioClipboard. Nice! Yes, that does what I envision. Like you said, it’s slow (both because of the number of tracks and because it’s not optimized for my specific situation).

That plug-in shows that I can accomplish what I need to do, assuming the mic tracks are arranged as mentioned above.

This is one of those situations (that I’ve been in too many times to count) where I won’t know the true pain points until I try a real edit/mix. My sense is that, with 10+ tracks and 5+ takes, auditioning the takes will be cumbersome. So working with a single stereo track during edit makes that much easier. I’d think that the 2-mix would also make 4-point edits (either proper 4-point edits via a script, or just doing them manually) much easier, as well. But it also might make such advanced edits less necessary.

tbh, the wow factor of Cohler for me (someone who’s never used it, nor edited such a piece yet) was moving around multi-track takes so quickly and effortlessly.

I reserve the right to be wrong.

Unrelated: I was having a bit of trouble getting AudioClipboard to recognize my dual-mono tracks. It worked once, but not the next time. I know that it relies on the filenames, and I’m going to debug to see why it didn’t recognize them. I’m guessing user error.

I really want to use vim for editing scripts during debugging. Is there an easy way to get Ardour to reload scripts to pick up my edits?

GhostsonAcid · March 8, 2026, 6:56pm

Hmm. At first I thought maybe I didn’t yet implement Dual-Mono detection properly if one uses the Manually Select Files To Use feature, so I just checked it. It is in fact there. So I just ran some tests and concluded your likely issue…

I haven’t mentioned this anywhere, but there’s actually one annoying caveat with how AudioClipboard finds sources that are currently in a project: it has to ‘see’ them on the timeline as at least one region (-doesn’t need to be a full-sized region though). → If it cannot, then the script assumes the file/source isn’t yet available, and thus proceeds to trying to import/embed as necessary. (…However, I did just discover a bug and for some reason it’s trying to embed a single side of a %L/%R pair, which is incorrect. I’ll fix this.)

‘Quick’ explanation:
When I began writing what became AudioClipboard, I could not at all discover a way to access the project’s Source List directly. … But I discovered that I could access sources tangentially via regions that are present in playlists. So, during Pre-Paste all regions are scanned once, and their IDs (and other attributes) are stored in a temp-table, to which appropriate matching and eventual duplication (during pasting) can be done quite reliably.

…
Now, this ‘tangential-pseudo-source-access’ method still bothers me a bit, so I’ll have to ask Robin again about this to see if things have changed in the Lua bindings, or if I just missed something all those months back (~which would be highly embarrassing, haha… ). But for now, this is how it works, and it still does a very reasonable job.

TL;DR, potential problem fix to try:
For any source you’re getting AudioClipboard to use that’s already in the Source List but NOT on the timeline, try placing just a single region, say “Take 1.1”, onto any track, then when you use ‘Manual File Selection’, select “Take 1%L.wav”, and it should find it and work fine. ~Then just use the Paste function as normal.

My guess is that it worked “once” because that source was available as a region somewhere.

Now, I would love to take AudioClipboard and trim it way down for this specific purpose: In-session source-swapping. All the building blocks are there to do this, although many of those ‘blocks’ are quite large in scope… I’ll consider it.

…
[PS: If most of this doesn’t help or is irrelevant, please let me know and I will debug further! Thanks!]

mkindred · March 8, 2026, 7:38pm

One thing is apparent to me: regardless of what processes I develop, editing such a beast is still challenging, it requires great care, and there are some steps that have to happen at very specific times.

Something as seemingly simple as time-aligning a single spot mic is much harder if you suddenly have multiple takes and regions flying around. When I considered how time-alignment would increase my complexity, I thought my workflow itself was flawed. But the same issue would happen in a fancy proprietary classical editing tool, as well. So I’d just have to make that decision early on in the process.

GhostsonAcid · March 8, 2026, 7:45pm

Oh, I forgot to answer this.

Option 1:
There is a built-in scripting window you can use in Ardour via Window → Scripting. You can just paste code in there and hit “Run” to execute it, -and it’ll print errors in the space below, and other stuff as dictated by the particular script being run.

Option 2:
You can also edit the script and leave it in the …/Ardour9/scripts/ directory, save it, and then use Shift-right-click to unassign its Lua button (in the top-right of the editor), then just left-click it, use “Refresh”, then find it again and assign it. It should then be the updated version.

…

And yes, particularly in your case, the exact steps you take and the order you take them in, is pretty important. But, like you also mentioned, you won’t really know what exactly you should do (and what actual difficulties you’ll encounter) until you get started on a “real edit/mix”.

-J

mkindred · March 8, 2026, 8:43pm

Actually I won’t know until I’ve had to begin over 10x on a real mix.