If I want to export a final mix of a song, and all of it’s stems at the same time, how do I do that? The normal export understandably only outputs one file, and the stem export window won’t let me export the master bus along with everything else, so do I have an option here?
I want to do this so elements like reverb and whatnot that are slightly different with every render are the same between the full track and the accompanying multitracks.
1 Like
We do not currently support that. Stem export (“file per track and time range”) and “file per time range” exports are considered two quite distinct operations (because often you want different settings for each). The purpose of each one quite different too: stem exports are typically to be able to move a session’s data conveniently to some other platform; regular export is to be able to create one or more audio files showing the current state of the whole session.
1 Like
Alright thank you. Whenever I completed a song, I tended to export the stems and master track from Reaper at the same time, master the mix itself, and then keep the multitracks in a folder close by so that if I ever needed to give someone the tracks for whatever reason, they’re just sitting there, organized and ready to go. It’s a small option that would be appreciated in the future, though I have no clue how difficult it would be to implement considering you say they’re treated as separate operations.
If you really worry about the minuscule, if any, difference in effects between the export and the stem files you really should also worry about the difference between your final listen and the export, since those are separate runs.
Also, if there actually are some (slight) audible differences there’s a 50/50 chance that the stem effects sound better…
You should do an A/B check between the master and the stems and check if you actually are able to hear any difference in the reverb tails and so on.
Chances are you won’t be able to do that, which means that you don’t have anything to worry about.
1 Like
That’s not necessarily true.
I can see a situation where you have an effect or instrument which produces a (pseudo) random result each time. This could be, for example, a vinyl simulation plugin or, more dramatically, a MIDI arpeggiator with a random setting.
In this case, a separate rendering run would produce a significantly different result.
Cheers,
Keith
1 Like
Part of my point is that if you have such an effect it will also differ from every run-though during mixing. Which means that your final mix won’t be the same as the exported file.
If you have an effect like that and need a 100% reproducible result you’d better record that result onto a separate track and use that when your mixing and exporting, instead of the entirely-random-at-every-new-run-through plugin/arpeggio.
You can create a new bus and connect the master to it (don’t select an output for the new bus). Then select that bus on stem export.
and/or
You can re-import the stems which will keep the changing elements if you want to do anything further.
4 Likes
I mean that is very fair. The subtle differences are more just me being pedantic then anything else, I admit.
Hey that’s a great idea! Thanks!
I’ve mentioned this before and been dismissed, but I still don’t understand the reason to have distinct hard-coded modes for different parts of an expected workflow, that can’t be combined.
Why not have just one type of channel strip, with options for input and output channel count and everything else, and use that for busses and master too? EVERYTHING is a channel strip, with enough options to cover all of the different uses.
- Multiple “masters”? Sure! Why not? Each has its own purpose, determined by the user.
- Export just one, or several, or all, or whatever? Yes again. Likewise for where to export within a strip’s signal flow.
- Might need two or more identical export pages/tabs, each with the same set of independent options, for projects that do have a strong sense of “master” and “stems” so that both can be preserved. But they are identical and can be used for anything.
For those that are still locked into “master does this, channel strip does that, etc.”, there might be a set of buttons to preset those options, and the default project(s) might have them that way already, but it’s still a set of independent options to mix and match as needed.
Beyond simple inertia, why not do this???
It isn’t simple intertia at all. It is learning from actual workflows used to produce recorded performances over many decades.
Multiple masters? Semantically this makes no sense, since the master bus is definitionally the place where all tracks and busses send their output in order for it to be audible. If you want multiple “master-like” busses and every track & bus wired to them, you can do that.
Export just one, or several or all, whatever? You can already do this.
“Where to export within a strip’s signal flow?” Again, export is definitionally done at the outputs of a track. If you want something else, add an export bus, send to it, adjust the send position, and export the bus.
Of course, keep that! Or more accurately, keep the capability to flow like that. But the exact same thing can be done by setting a bunch of the same ultra-flexible component to the required options for each role.
I think the challenge here is accepting a definition that is, as far as I can tell, completely arbitrary. Yes, it’s based on a long history, but if you ignore the past, and the memory of the past, what does it still have to stand on? If everyone learned a different way, would they drift back to this? If so, why?
As a challenge to the definition, I run a hybrid local and online meeting a couple of times a month, that uses Ardour as a plugin host (mostly noise reduction and compression, and heavy ducking because the meeting’s echo canceller isn’t designed for these acoustics) and as a virtual mixer / router that also accepts external automation commands. There are at least 3 different audible outputs from that, that all have different things fed to them: the local room, the remote participants, and the video recorder. Which one is the master? All of them equally could be. Thus, “multiple masters”.
(Because I couldn’t decide which to arbitrarily assign as “the master”, I just don’t use that bus at all. Nothing routes to it.)
Using a loose analogy from analog electronics in general (including audio, but not limited to audio), why not just stick an oscilloscope probe somewhere at random and record that? And to continue that analogy, what about N probes, all in random places, to an N-track recording?
If you want a stereo master, just put two probes at the final outputs of a channel strip that you’ve (eventually) routed everything to. Maybe even have a button that does that for you, but keep the ability to do anything else too.
Yes, that works, but it still feels clunky compared to a needle at the end of a wire that goes to a line input of an analog console…which I do quite regularly to test my custom “toys”.
And yes, if I do that a lot and use a bunch of channels on my analog console, then it’s pretty much the same as what you suggest: an additional bus for each export channel, with no other purpose, and the “needles” are aux sends with 1:1 connections to those busses. But it still breaks the mentality of, “I want that signal right there,” while I reconfigure / redesign the virtual console to get it.
Somehow, creating the physical needle-on-a-wire tool and using an analog channel strip, doesn’t break that mentality. Maybe because I only do that once because I know I’ll need it, and then the, “I want that signal,” mentality forms, after I already have the tool???
So maybe I can do that up front with the virtual console too, and then make it a template. Or a complete session to filesystem-copy and then run the copy, like I do for the series of 32-track raw recordings that I’ve been doing…
And there’s a component too, of what might be a disguised bug report. Remembering my recent experience in trying to get those 32-track recordings that I made in Ardour from a 32-channel USB interface (digital console, actually), into a 24-channel standalone DAC that requires 24-bit integer mono WAV files. Ardour’s internal format is 32-bit floating-point mono WAV’s - which is almost there already, just needs a datatype conversion - but for some reason Ardour’s export of that didn’t work and I’ve forgotten why. Audacity does work, by importing Ardour’s internal WAV’s and immediately re-exporting from Audacity. I get the impression that that’s not the way it’s supposed to be done, but if Ardour won’t do it…
So that’s another part of my motivation to have everything be the same thing with options galore to make them into a variety of roles. The same troubleshooting / maintenance that makes someone else’s commercial release work, would also make my raw multitrack work, and whatever someone else wants to do with it too.
Or in other words, reduce the number of things that have to be maintained, by consolidating a lot of it into what is actually the same thing. Making that work, also makes everything else work, along with some other creative uses that would have been impossible before.
As it is now, it feels like all but a few of the separate and similar things have been forgotten, and their problems either largely unknown or de-prioritized in favor of the more common uses. Which more-or-less reduces its overall (supported) usefulness to just those more common cases, while all of the others become more and more “hacky” as time goes on because what was supposed to work…actually doesn’t and has a low priority to be fixed, if it’s even reported in a way that gets it on the list.
If you want an actually modular environment, Cardinal and/or VCV Rack provide that for you.
Ardour isn’t trying to be a modular environment. Nevertheless, almost everything you’ve mentioned can be done in Ardour, just without the wire line drawings. Ardour doesn’t require that you use a master bus, and if you don’t, no bus is “special”. Ardour can record from any point (more or less) in the signal flow pathway through a track, and sends and returns can be positioned anywhere in that same signal flow. You’re not describing things that Ardour can’t do, you’re just describing a way of doing them that Ardour doesn’t support because we’re designing around a different fundamental model.
As I said at the top, Cardinal and VCV Rack and several other completely modular systems exist, but Ardour exists in the space of timeline & channel-strip oriented DAWs, and so you’re not going to be dragging wire ends around to record things any time in the foreseeable future.
1 Like