You still have to export from Audacity, is doesn’t write directly to an audio file.
I think OBS can record straight to a wav file though.
1 Like
I will point out that, even in the old analogue world, it was actually quite rare (I would say almost unheard of) that the original recording was the final product.
Pretty much every commercial music recording from the 60s onwards went through some sort of multi-tracking, editing, mixing and mastering. Yes, they were much more limited in what they could do and this forced a workflow and decision making process which (when done by an expert) often produced fantastic, organic sounding results. But they still went through a process to massage the material into a shape more appropriate to the audience and distribution media, and this was commonly a very lengthy process.
This involved days, or even months, of post-production in the studio, weeks of mastering and then, finally, “exporting” the master tape to vinyl or other media.
And this was even done for recordings of live performances.
Comparatively, clicking “export” and waiting for a few minutes on a modern DAW is much more immediate.
Heck, you can go from a performance to a reasonably mastered version of that performance to distribution and have and audience within an hour, and that’s not considering live streaming.
Cheers,
Keith
All good points.
I actually have an XR18 myself, and used them in a few other rigs that I built. Don’t care for anything less, even if I’m only using two ins and two outs, because all of them trade the immensely useful USB sound card for a practically useless flash drive jukebox that can’t see a lot of your library because it requires a specific file format and doesn’t resample. And if it loses power without an explicit stop (too much cognitive load for one operator, so they make that sort of mistake…), the entire recording is gone. So I always use an '18, and a separate computer for the jukebox and recorder, whether that’s a tower or a Pi or whatever. And for the cases where the computer can lose power too, I put a UPS on it, with automatic graceful stop and shutdown. (A Pi UPS can be a similar size to the Pi itself; they don’t have to be big and bulky.)
Anyway, it just feels…odd…to have it so close (mono standard WAV’s that I can grab immediately and use elsewhere - nevermind the original intent behind them and that they’re buried in the project folder: it works), and yet everyone says the “last step” from a user’s perspective is such a big leap and not happening.
Yes, I know that perceived difficulty from someone not directly involved is rarely accurate ( xkcd: Tasks ), but it still feels that way. And “everyone does it this way” is not necessarily a good reason to not add something new that doesn’t affect what’s already there. (options with defaults, or another button, or…) Technical debt is, which should shift the priorities to cleaning it up before doing anything else at all (and motivate good design in the first place, which takes longer than just tacking stuff on), but I haven’t heard anything about that here.
Seeing that the Master bus presently does not have a record button like the individual tracks do, what would the implications be of adding one that behaves differently from the rest?: A single multitrack file in a configurable location, and a configurable filename with variables. Things like %project name%, %date%, %time%, %incrementing count%, etc.
Roughly equivalent to the “Tape Out” of a physical console, which is a copy of the Main Out (roughly even split, it seems, between pre- and post-fade, but never an option for some reason), and clearly meant to drive a tape recorder with the final mix.
Some workflows would have it directly replace the Export function, while others would keep Exporting as before with no change, and others like mine would have something useful that never existed before.
For OBS recording WAV’s, I suppose that’s another thing to try, but I don’t have particularly high hopes for it. OBS has had a problem with technical debt for years, and its devs seem to ignore that and continue to add more features while the old problems stay there. It’s not just that it doesn’t have good audio processing - the processing itself is okay for what it does, and sounds fine, but it’s missing some important tools, and what it does have is entirely blind - but its audio outputs (both file and physical) seem to have buffer-management problems that the user has to carefully work around and not trigger.
For example, some sound cards are perfectly fine, while others progressively delay OBS’s headphones over time until they’re completely useless. Only OBS has this problem; everything else uses those cards just fine. The solution to that, if you really need it, is to send OBS’s audio out to a virtual thing instead, that is guaranteed to use the same clock, and then send that virtual thing to the asynchronous hardware.
Again, nothing else has that problem, only OBS. As if they tried to roll their own and naively got it wrong, instead of using a library that already works. That problem has persisted across (at least) several major versions, and they’ve even defended it (!) with a blatant remote-network-streaming type of argument in a context that is absolutely not that!
Meanwhile, the soundtrack in the video file sounds like it’s frequently dropping several complete buffers in a row (instead of a single sample here and there for a quick-and-dirty re-sync, which is still not the “right” way to do it but much better than that!) and replacing those missing buffers with silence…
But a different PC does work, with the same version of the same OS and the same version of OBS. I have system load indicators on both (that come from the OS, not from OBS), and both have some headroom…
Anyway, it’s…hard for me to trust OBS, and I really only use it because no other open-source thing has anywhere close to its subset of features that does work.
Be careful of the details. When most people think of “standard WAV” they would likely assume PCM, while the files created by default in Ardour are floating point. You can change that in the session properties dialog but you have to explicitly change that if you want files stored as PCM (integer) data in WAV files.
A bus does not record audio data to disk, while a track does. It makes no sense to have a record button on a bus because a bus never “records” in the sense that word is typically used.
What you are asking for is effectively a redesign of the distinction between a bus and a track in Ardour. I don’t want to speak out of turn (not being an Ardour developer), but that seems unlikely at this point.
Of course it’s possible for an app to only understand integer and not float, but everything I’ve used can take just about anything. I suspect it’s because they all use FFMPEG, which can itself handle pretty much anything, and they don’t actually have to do it themselves.
Is that the only difference? I was wondering that myself, because as far as I could tell, there isn’t one. So I just use tracks for everything, including submixes. No distinction that I can tell, except arbitrary and therefore unnecessary. Is there something that busses do and tracks don’t?
This feels a bit like aux sends vs. subgroups on a console…and then someone noticed that they’re the exact same circuitry (a mix bus), and gave them all the exact same controls, thus removing the distinction and having a TON of mix busses that can each be used for either purpose. I first saw that on a medium-format Yamaha analog, and then a large-format Yamaha digital, and then I saw that Behringer digitals do it too.
Or…maybe adding a direct-out recording feature to all busses would be a reason to keep that distinction, and be even more flexible than only having it on the master. Each bus records a single multitrack file that matches its own channel count, in a user-specified location (same location for all busses), etc. Meanwhile, tracks record internally to the project as they do already.
Agreed.
Why is it such a big leap. I really don’t understand this part. Exporting a mix is pretty trivial, especially once you’ve set it up with the export parameters you want (formats, naming, even “mastering” normalisation and limiting).
But “no-one does it that way, and there’s not really a good reason to do it that way” IS a good reason to not add pointless capabilities that (statistically) no-one will use.
Especially if those changes, potentially, require rework of the architecture, which they may do.
So far, I don’t see a use case for what you are trying to do. And I don’t mean a compelling user-case, I mean any use-case. Maybe there is one, but you’ve not presented it beyond a major misconception of how analogue workflows used to be and your perception that it could work differently.
As the meme goes: Change My Mind.
You mean it does not have a record arm button. That is because it has no-where to record to:
Architecturally they are (as I understand it) different. The primary function of tracks is to record and edit audio (or MIDI) data. As such, tracks have playlists and regions. When you record to a track, you may be creating multiple regions and sources (and playlists) which results in multiple files.
The primary function of a bus is to sum and aggregate multiple tracks into a single stream. And whilst, yes, it would be technically possible to have a record function on busses, it would be architecturally completely different from normal tracks. And I’m not convinced there’s a use-case for it.
If you do want to direct-out record from a bus, there’s always Jack/Pipewire and connect a recording application to that bus output, as has already been suggested with JackRecorder. You could even use the Master bus for this.
At this point, you are really just using Ardour as a plugin host rather than a DAW. If that works for you, great, but that’s not it’s primary function.
Alternatively, if you really are just trying to avoid a couple of clicks at the end of your workflow to do the export, there’s always LUA scripting:
Cheers,
Keith
There’s also tools like parec:
Audio recorder:
Krecorder:
One or more of these, attached to an Ardour bus output, may work for you.
Cheers,
Keith
Pro and consumer workflows are a bit different. The official recording of an event, vs. a random attendee, for example. The official one has a lot more gear that takes a while to set up and might even be baked into the venue itself, whereas the attendee just holds a phone or DSLR or even a pocket tape recorder. Explicitly arm everything, then rec/play, capture everything separately and dead raw to surgically fix all the flaws later, etc.; vs. start / stop / done, then some time later, turn on again, rewind, and watch / listen. Or nowadays, start / stop / publish / view-count increasing before even reaching the parking lot.
I actually learned on my parents’ consumer gear as a kid, and slowly grew into more serious toys from there. So I really really want to keep the ease of “just want to…” that the consumer side has, even if I have to spend some effort up front to make a rig that does that with all the processing that a particular application needs. Don’t need to capture every detail to fix later, just a general record of what happened, in a way that is actually useful and not jarring. So essentially, “live to tape”…except it’s an SSD now.
It really needs to be simple to use, eventually, because I want to train some people on it who will absolutely not learn how the pros do it, so as to jump through all of those hoops and think that that’s normal like actual pros do. My trainees are going to see every one of those hoops at once, from an ant’s perspective, call it “too complicated”, and refuse to touch it. So I eventually need something that is both fully capable on the back end (because it really needs that) and can be made dead simple on the front end (because the operators need that), even if I have to spend some effort in between to make it happen that way.
If you think that’s unachievable, consider the details of echo cancellation, for just one example, and what it actually has to do, compared to a middle manager who only wants his speakerphone to work. There’s no way he’s going to understand even the first thing about EC, and yet he uses it daily. That’s where I want this rig to be, with all that it needs to do.
The primary reason I’m using a structured DAW instead of a generic plugin host with freeform connections is because of the PFL button. Structure the channel strips in a way that puts one of those at every potentially useful place to check on things, and the debugging goes SO much faster! I have that routed to some headphones that are almost never used now because the processing pretty much works now, but they were immensely useful in setting it up, and now here we are.
I did initially set this up in Carla, which is a generic plugin host with freeform connections, because I could make the diagram match or even become my documentation, but the PFL function was important enough to switch and rebuild.
…And it could entirely be that I’ve never actually understood what a DAW is really meant for. My first discovery of one (Krystal, later bought by Presonus and greatly enhanced to become Studio One) was a search result for “software sound board”, as in a software emulation of a physical console that can play multiple separate tracks at the same time (synthesized from MIDI at the time into separate WAV’s, and then loaded into the DAW as audio) and mix them live with tweakable processing, both for live mixing practice and just for fun. Not really interested in anything more than that until I saw it as…still an emulation of a physical analog console and outboard processing that I would set up for a given live task, except that it fits inside the box instead of sprawling over the entire room.
Given that framework, maybe it’s clearer why I’d want to “just plug in a consumer-type recorder at some random point and hit ‘record’ on it”? (like I can with an actual analog rig, even if it’s not the generally-accepted pro workflow to do that)
Though I guess putting it that way would be more like a plugin that records wherever it happens to be in the chain, instead of the host doing it at some fixed point(s). Hadn’t thought of it like that yet. And if an OSC message that I already have the structure for, can control plugin parameters…and one of those parameters is start/stop in a recorder plugin…maybe that’s a path worth pursuing???
This plugin on the master out may be an option:
Hit record, play your music, hit stop, File >> Export
1 Like
Good find! I’ll have to play with that. Thank you!
You’re missing at least 4 steps that are all going to be right up in their faces (yes, they’re that sensitive, and I may have missed some):
- Switch to another app to start recording
- Switch back to the main controls that they also rarely use but need to be available
- Switch back to the other app to stop recording
- Navigate dialogs that they don’t read (actually, experts don’t really read them either; we just already know what they are and how to dismiss them)
And that’s assuming that the arming and such is already included in the session file that I protect from being overwritten. Consumers don’t do that either, at all.
The plugin that Schmitty found will also require some changes to my script, to find and move the recording file from where the plugin puts it to where the users are going to look for it. But that’s easy to do, as long as the filename and location are easily predictable, which it looks like they are.
If you think the app switches are inevitable…OSC. I already send them from the main controls to Ardour to control the audio mixes, not as direct controls but as part of the requirements for a given overall mode. So it’s nothing to just add some more to control the recording. Thus, no app switching, and hopefully no dialogs.
Which other app? Everything I’m describing is within Ardour
1 Like
That seems like a very complicated way to automate something since you are already using OSC. Why not just send OSC messages to aux sends and faders, bus faders, and VCAs?
Not completely following what you are describing there, but by “main controls” do you mean your app which sends OSC? Or is that the “another app?”
If you are automating everything through OSC have you checked whether you can just do everything from your OSC app so there is no need to switch back and forth? There is an OSC action for export
The other app is Ardour. My users will not normally see it. They’ll see the control app instead. So anything that must be done directly in Ardour requires an app switch, which I want to avoid.
Because the OSC messages are just one-shot, instant full-effect. If I send 0dB or -200dB directly to a level control, I get a hard cut on or off at that point, which is somewhat jarring. So rather than send a dense stream of messages, which takes its own code structure to do, I just send one to a control signal and let a sidechain dynamics processor create the fade for me.
Hmm…it would probably take a lot of work, and careful design to not make it annoying like Microsoft’s Clippit was, but I think they might have been onto something with the concept at least, of trying to figure out what the user is actually trying to do and suggesting ways to do it. The character and popup speech bubble are definitely a bit much, but maybe a small dot in the corner would be okay? Click on it to see the suggestion.
Or maybe just have links all over the place that go directly to the relevant documentation for each thing.
Either way, discoverability does seem to be a bit lacking here, which seems to be a common problem with nearly all capable and flexible things. I’ve seen people ask to hide settings, but I think what I need at least, is a description of what each thing actually does in “expert mode” as those people have called the present state of things, and why it’s there, so I can actually use it as intended, instead of hacking what I already know and moving on with no idea that there’s a better way.
Third-party tutorials are notoriously out of date and have the same problems of ignorance as I do, so I think it needs to come from the developers themselves, or from “power users” that do use it “correctly”…if they can be convinced to take time away from their own projects and make (yet another) tutorial instead, that is aimed at people who know far less than they do and may even come from a different world than they do…or maybe they come from a different world themselves and can do the translation as part of the tutorial…
Anyway, how long does the export take? I don’t have a lot of time between stopping the recording and showing the file to the user, and these recordings are about 90 minutes or so.
And I don’t want to clutter up the session with a bunch of internal recordings that will never be used again. Is there also a clear function that I can use after exporting, to go back to what it was when it first opened? Or maybe it’s better to have the script copy a session that is never used directly, run the copy, and then delete the copy. Then it’s also immune to whatever a user decides to poke around with and then save…
Ah ok, I haven’t read the entire thread so I must have missed that part.
Yeah, it was meant to be a short Q&A, but it kinda exploded. Good discussion though, with far more benefits that I originally had in mind, so I’m glad it did. (and still is…)
Bitfocus Companion will send OSC, I would look into that to ideally control all your apps at that point, and you could easily automate multiple steps with a single button press then if needed. Potentially, depending on your other app, you could have everything controlled through a stream deck for instance.
Then again I still lean towards I would do just standalone recorders, and then maybe control them through Bitfocus myself. I do a lot of these types of things for Churches etc. with volunteer crews as part of my consulting and design.
Seablade
That depends on disk speed, CPU speed, and how many plugins you have running.
With an SSD and minimal plugins and no loudness analysis maybe a couple of minutes.
You don’t have any existing recordings you can try?
Like a user manual?
Although I have to admit until you know, it may not be completely obvious that the OSC section is under “Control Surfaces” in the table of contents.
1 Like
I believe you can also use OSC to trigger an export of recorded audio, or to launch a LUA script which could do an export.
Cheers,
Keith
I agree.
But, really, no-one was using the workflow you describe 40-50 years ago in the analogue era.
More specifically, there was hardly anyone who had access to (at the equivalent prices today) 10s of thousands of dollars of multi-track studio equipment and outboard processing gear, and who had a significant audience to distribute to, did this. People who had these capabilities would generally edit and post process the audio which, by definition, would take longer to do than exporting in Ardour would take today.
Anyone who was dong that style of recording were only doing so because they didn’t have the tools available (and large budgets required back then) to do that post-production work. And that meant they also probably didn’t have an audience of more than a few dozen people to distribute the result to.
You are, by the way, talking to someone who was doing recordings of, and for, low-budget theatre productions in the mid 1980s. If we had the capabilities (and audience) to improve the sound quality by post processing, we would have. And we would have loved to have been able to do multi-track.
We didn’t record like this because we didn’t want to, but because it was impossible for us to do anything else. Did it result in better recordings than if we had the facilities that are readily available and affordable today?
Absolutely not!
And even without those unaffordable studio tools, I forget how many hours we spent tidying up tapes with a razor blade to remove noisy or unrequired sections of a performance
I honestly think you have formed a romanticised, idealized view of old-school analogue workflows and practices which really only exists in your imagination.
These days, you can get studio quality compressors, reverbs, EQs, gates, and multi-track capability for the price of a cheap computer and audio interface. And it will, in many ways, exceed the capabilities of the gear available to high-end studios in the 1960s and 70s.
That is the setup you are using, complete with automation (OSC) that could only have been dreamed about 40 years ago and you are, effectively, trying to compare that to someone trying to record an amateur performance on a cheap Radio Shack cassette recorder and microphone.
The modern equivalent of the amateur setup you reference would be for you to launch the voice recorder on your phone and use its built-in mic. But that certainly wouldn’t work for the setup you describe.
I do understand that you want a setup that’s as simple to use as possible but it sounds like you have a very specific and unique use-case that you are trying to achieve.
There are ways to do this which include using more automation (LUA scripts and/or OSC control) to trigger the export either automatically at the end of the recording, or with a dumbed-down control.
Or you could just train the users how to perform the very straightforward export process within Ardour: if the session has been set up with a session template with the required export parameters, it really is as simple as CTRL-E, ALT-E to export the whole session and open the folder with the exported files.
Arguing that Ardour (or any other DAW) should do this is, IMO, a dead end.
Cheers,
Keith
1 Like