External Wav File Editors Yet Again

Community Ideas for Ardour
#1

I see this topic has been discussed on at least twice before in the last three years on this forum, but here goes again.

I want to make an external editor modify wav files under the feet of ardour or else be persuaded this is not the best option. In my case, the external editor is either a homebrew version of melodyne (monophonic) or also the real Melodyne running under wine. This real Melodyne was integrated in to the Traction DAW on linux to some extent, but I decided I don’t like Traction as much as I like Ardour.

My proposed work flow is:
1 Render a single channel as a 24-bit stem export wav file using Ardour.
2 Reload the exported stem as a fresh track into ardour. [I think Ardour will copy if from exported to interchange sub folder in my project?]
3 My external tool automatically finds this in the interchange folder using a couple of heuristics and also loads it.
4 I manually use the external tool to change the now-shared file contents but not duration and not any other significant aspect of metainfo, format or layout, such as offset of the PCM from file start. I hit save in the external tool window and return my focus to the Ardour windows.
5 I do nothing explicitly in Ardour but expect Ardour to play and export the modified sound and display a modified envelope and metainfo through the Ardour GUI, such as update time in the right-hand-side sources listing.
6 Repeat steps 4 and 5 as much as I like.

Reading the previous posts on this topic, I suspect most of this to work fairly well? Am I mad?

I have not looked at the coding or behaviour of how Ardour pre-caches an envelope display. On other DAWs, this information is stored in auxiliary files and the last modification time of the files is used to determine if the cached information is dirty. Perhaps Ardour just keeps this in core instead of secondary storeage?

An earlier post by Robin suggests that Ardour is coded assuming all saved files are `imutable’. What I really need to know is will something go unexpectedly and badly wrong if this assumption is voilated in the way I propose. I think he also mentioned the need to do a session reload after proceeding in this way.

#2

It will already fail earlier.

During (2), Ardour opens the new file for reading, and since Ardour streams data from disk it is kept open.

During (4):

  • Linux/Mac: the newly written file has a new inode. Ardour will not see any changes. – On Unix, one can even delete a file and any application with a valid file-handle can keep accessing it.

  • Windows: The external app cannot write to the file. – For as long as some application has a [read-only] file-handle, no other application can write to it.

Ardour will have to close (and re-open) the file as needed.

–
For the case at hand, the preferable solution would be to add ARA support to Ardour. That way there can be tight integration with melodyne without resorting to a standalone external app.

#3

That is a most helpful explanation of a likely pitfall. Thanks very much.

I wonder if you know a little more. What about, on linux ext4, if for instance the file is opened by the external tool and modified without changing its inode, perhaps using mmap or just opened O_RDWR ?

By ARA do you mean Archivaldo Resource Archive which is the main google hit for that acronym?

Thanks v much.

#4

ARA stands for “Audio Random Access” (follow the link). It allows a plugin to access raw audio data (like it was a file).

From the linked repo’s README:

ARA Audio Random Access is an extension for established plug-in standard APIs such as VST3 and Audio Units to allow for a much-improved DAW integration of plug-ins like Celemony’s Melodyne which are conceptually closer to a sample editor than to a conventional realtime audio processor. It enables plug-ins to read audio samples from the DAW host at will, allowing them to implement more sophisticated processing algorithms not possible when being tied to individual realtime buffers.

This does not allow the plugin to modify the data, but the plugin can show the waveform, and allow a user to preform operations. All edits are saved as meta-data. Later the plugin can apply the changes in realtime (as if the file was modified).

It is an extension made by Celemony, and recently it was re-licensed so that GPL apps can use it as well.

#5

It’s not file-system specific, but happens a layer above. mmap won’t help either (that also uses a fd).

Anyway take the following example:

Ardour (really libsndfile) reads wav-data from at an offset of 1000 bytes from the file-start.
Now the external application modifies the file and adds extra meta-data at the beginning of the file.
Ardour would have to adjust the read-pointer accordingly, but cannot know that.

1 Like
#6

Thanks.

Ah yes, you are right, but I did say in my original posting that the external tool would not alter any significant metadata, especially the offset of the PCM from the file start.

I believe the mmap works the same way as shmemget on some unix variants and can indeed be used as a form of IPC. And I am not quite sure how relevant the use of a file descriptor is. I’ll perhaps give it a try tomorrow, since that will be quicker and easier than thinking about it any further. I’ll let you know.

… thanks

#7

Been thinking about this too.
I would not work on the same file.
Here is what I would do:
Save the Region you want to edit externally.
Copy to a temp location.
Pass the copy to your editing software.

Whenever ardour regains focus, check if the copy has changed (saved).
If it has, offer dialogue to either replace with edit, replace and keep backup of original, keep both or cleanup.

A bit messy, but secure.

Are ardour windows focus aware?

#8

Are ardour windows focus aware?

Yes, certainly on linux a piece of software can be notified when focus returns to one of its windows.

Last night, I had a go at changing a mmap’d file in the interchange folder and I found the following three points:
1/ An external program can change the interchange file contents when it is mmap’d and Ardour simply plays the modified sound just as you might expect without any reload steps. So it does look like this is a basis for me to work on as a stopgap solution to accelerate workflows.

2/ Modifying the mmap’d file does not change its modified time as listed by ‘ls’. I imagine this would mean that ftell or some other system call that is suppose to spot changes would not get triggered by the remote modification. However, the ‘touch’ command does change the modified time without changing the contents, so it would be a simple matter for the external tool to ‘touch’ the file when the user hits the equivalent of ‘save’ in the external tool.

3/ Ardour considers its cache of waveform peaks to be valid if its modified time is after the modified time of the the wav file (give or take six seconds of ‘slop’), so the `touch’ I’ve just mentioned seems to be a sufficient basis for Ardour to know when to recompute the waveform peaks for the editor display. Also just deleting the peaks file when the external tool modifies the wav file would likewise imply they need computing again (but would involve mirroring Ardour’s peaks file naming convention in an external tool, so is less robust).

Howver, when running, Ardour does not seem to check whether the peaks have gone out-of-date on a regular basis, and so a small modification to the Ardour code to make this happen could be useful. I might be able to implement a lightweight one myself instead of waiting for ARA suppport. Responding to the focus event is one possibility, but re-focus perhaps happens a little too often and I’d probably define a specific inter-process event, such as presence of a shared file in /tmp to trigger the required peaks reconsideration just when expicitly notified.

Moreover, since my primary application is manual pitch correction, de-essing and tone modification, there is only a minimal amount of retiming or volume changes typically being made by the external tool. This means the macroscopic peaks waveform is going to be hardly affected most of the time anyyway. Clearly, if I am then going to move on an slice or recomp a tuned comp then I’ll want to trigger, one way or another, the recomputation of the peaks, such as ‘save session’ and then ‘open recent session’. But this will be a lot rarer.

So I find that Robin’s warnings that this simply won’t work are possibly not correct? Or else I’m being very silly and still going down a deadend path.

DJG

1 Like
#9

Ardour (or rather libsndfile) does not use mmap for streaming data from disk.

And let me repeat: This also only works if raw PCM data is modified in an existing file while all headers and meta-data is not modified. Also the external app must not do a common read-modify-write (unlink + re-create).

3b) the correct way would be to use inotify – and the equivalent on macOS and Windows.

Hard to say how much that will affect disk performance though. It likely needs to be disabled when recording.

On GNU/Linux you can probably make it work for yourself. but it depends on the app you use to change the file. A common read-modify-write will unlink the file, not modify its content in-place. mmap can work if you don’t use MAP_PRIVATE. – And then there’s macOS and Windows and *BSD.

–

If I had to implement this, I’d export the file, launch an external program and when that terminates, re-import the file and replace the region (or rather the source of each region that references the given source-id).

1 Like
#10

On GNU/Linux you can probably make it work for yourself.

Thanks Robin, you were right. It seems to work for me ok on linux. I altered the backend of my vocal editing program to modify the file using mmap without using MAP_PRIVATE and it works well.

There’s a few positives of doing it this way:
1 The plugins on the Ardour channel strip and pan settings and so on are all applied on playback.

2 There is no need to export a stereo backing track with careful time alignment to the vocal editor since playback with backing enabled can be peformed by Ardour. Operating Ardour transport controls on a control surface means I don’t even have to change focus of the keyboard or mouse: I just move me arm to the control surface.

3 On systems with only one soundcard, I have a problem using external sound tools while Ardour is running. Ardour seems to take out an exclusive lock on the ALSA soundcard it is using. Hence, to use the audio output of an external tool, I’ve found it necessary to completly exit Ardour when auditioning edits made in the external tool. This new approach avoids that problem. I wonder if there’s a way around that with the workflow suggested at the end of your last post? [On larger installations I get round this problem simply by having pulse audio running via SPDIF to an external DAC that is completely independent of the soundcard in use by Ardour.]

… the correct way would be to use inotify …

I’ll see if that works, since currently the 'Session->Cleanup->Recompute Peaks Files is not working for me, wheras Control-S, Session->OpenRecent works fine for refreshing the peaks files.

Thanks very much indeed.

#11

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