In some cases, it is important to record in a perfect synch with the existing audio. There is an instruction on how to do the Latency test and then set the Latency Compensation (Latency Test).
In attachment, you can find two macros that automatically set the latency compensation for you. Important rule is to allow mic to listen to the audio. Enable Overdub and make sure that the headphones are close to the mic or that the loudspeakers are enabled. Yes, you can do this test just with the loudspeakers/monitor speakers.
Why there are two macros?
Good question. The very true answer is because Audacity crashes when a plugin contains the command (aud-do-command “Undo”). I was not able to overcome this problem. So instead of plugin I had to switch to the macro (to undo the temporary steps) and instead of having one macro I had to split the code into two macros (only the second one must contain the undo commands).
How to use it
Run the macro Set Latency Compensation 1.
Be silent and wait 2 seconds until the recording is done.
Do not click/select/deselect anything. Immediately after the recording stops, run the macro Set Latency Compensation 2.
Note: This macros were developed in Audacity 2.4.2.
The slight downside is that it leaves some undo data in Audacity’s temp folder until Audacity is closed, but as it’s only a few seconds of audio, that should not be an issue.
I did not notice that post
I tested in v2.4.2 and it does not work for me. I had the same problem that the macro does not wait until the recording is done. It continues with the next steps and this interrupts the recording. Can I do something with this problem?
SelectAll:
RemoveTracks:
This works for an empty project. I was thinking to allow to set latency compensation also in the project with some data on tracks. I need to mute all existing tracks. And then return it back. Now I got an idea - I can store the mute state of all tracks and at the end of the macro to restore the mute state of every track. This is not difficult.
I just went through your macro code. It is very interesting to see different, but similar approach to solve the same problem
Of course, my level of Nyquist programming is still at kindergarten , when I compare it to your level.
I have a questions: Why do you store the value directly into scratch? Is it safe? What if I have another tool that stores something in the defined variable in scratch?
That was a problem in older versions of Audacity. I don’t recall exactly when it was fixed - I thought it was fixed in 2.4.2, but perhaps 3.0.0?
You could always open a new Audacity window (“Ctrl + N”).
Personally, I wouldn’t want to be messing around with setting up latency compensation (either manually or via a macro) while I have valuable unsaved data in the project.
When using scratch, because scratch persists until Audacity is closed, the developer needs to take steps to avoid data collision.
Usually this is done by using property list with property names that are extremely unlikely to conflict. Well behaved plug-ins should clean up after themselves when possible, and certainly should not leave large amounts of data in RAM.
In the case of this macro, scratch is short-lived as its value is deleted at the end, and it’s a very small amount of data.
Note that the macro also cleansscratch before use with the same code as it uses to clean up at the end:
, when I compare it to your level.