Editing the audio while it's being recorded

Hi!

Could it be possible to edit (slice, move, crossfade, duplicate etc.) a clip of audio that is being recorded in the very moment?

Let me show you a scenario:

One man is reading a book in a studio room. In the second room, a producer is capturing his voice and he’s performing editing (cutting out bad takes etc.) on the material on the fly. Why should he wait until the reader finishes?

Could such a task be performed with Ardour?
If not - what would be needed to make it possible?
Who would want to use this? (I know I would, and a friend of mine too)

unfa: this would involve major redesign of several basic assumptions of Ardour’s internal design. It is certainly not possible at present.

interesting idea… but I can’t for the life of me see how that is useful… for live functions … something like SooperLooper would seem more suitable.

It might be useful (and easier to implement) to allow you to split the track being recorded (as when splitting a region with the ‘S’ key) so that the part before the split then becomes editable, while the region being recorded after the split still can’t be edited.

I can’t really understand why you’d want to edit while recording though.

There are definitively workflows that require/benefit from the ability to edit the file that is being captured. I haven’t tried in A3 , but I recall in A2 it wasn’t possible to edit / apply fades, move existing audio files while the transport was in record. Has this changed in A3?

I’ve tried this and all I could get in A2 was to stop recording for a while and continue it immediately - with Follow Playhead off this seems to be doable. If Ardour had a special function that would split the recording (without loosing any material, or leaving a short pause to keep timecodes right) like anahata wrote - it would do for me.

Why this could be useful?

I’m working on audiobooks. If you have two people in the studio, the lector, and the producer - one is reading his text, while another is sitting there and bore himself. However he could take advantage of the fact that he’ve just heard what the lector did wrong, and he sees, what he’ll need to cut-out later on, why not do it straight away? I think it could save a lot of time.

Future improvements?
I can see having (optional) two-playhead mode. It would make one playhead for recording (red), and another one for playback (blue). This way, the lector could read on, and the producer in another room could even play back parts of the material to check if he have cut it right, without having to say “wait a second, I gotta edit this one”.

The “dirty hack” with manual restarting the record process will work for me anyway. I can sacrifice a short piece of audio that will be lost while doing this - I can restart while the lecturer is turning pages, drinking water or taking a short rest.

I don’t want to say this should be a top priority feature to do, but someday, having a (turned off by default) dual-playhead mode and the ability to listen to something while Ardour records something else - or even the ability to split a region that is being recorded without restarting the transport, could be useful.

This is rather an exotic need, and I think I’d rather support fixing bugs and making Ardour more stable and reliable than crazy-feature-rich.

Thank you Paul, for all your work!

I have a very special case need for this: my Ardour workstation is a Harrison X-dubber, and it’s connected to a 96K audio network. But video really prefers 48K. I’d like to turn my Xdubber into a high-track-count real-time sample rate converter when writing to disk. I.e., 64 tracks in, 64 tracks out. It seems to my naive brain that decimating 96K down to 48K and then writing it out is potentially easier than writing every…single…96…K…sample. But I haven’t looked at the source, so don’t know for sure. I have seen others wanting to use real-time sample rate conversion, but usually as an actual audio I/O device (which runs into troubles because sound cards don’t like to operate at multiple frequencies). But data is just data, and it doesn’t need a sound card to write data. Any chance?

michael: it sounds as if you are asking for “use hardware running at 96kHz but read and write disk data at 48kHz”. Is that a correct understanding?

Paul, that is exactly right.