Optimize Arm Tracks Command

[murat k.]

"Arm Tracks" command that we use for recording Audio tracks is not fast enough as compared to Auto Arm feature we use for MIDI/Instrument Tracks.

The problem in this command increases and felt proportionally by the track amount in the project.

MIDI tracks recording starts instantly with the Auto Arm preference when recording. But in the same project after applying "Arm Tracks" command to an Audio Track, we have to wait for the commands process completion to start recording.

However clicking on the record button on the track completes the process instantly.

So the issue is related to the "Arm Tracks" command. And what it does is directly related to the amount of the tracks in the project.

Edited November 12, 2022 by murat k.

[David Baay]

4 hours ago, murat k. said:

The problem in this command increases and felt proportionally by the track amount in the project.

Ctrl+R arms *all* tracks, Alt+R arms only the focused or selected tracks. Does that not cover it? 

[murat k.]

8 minutes ago, David Baay said:

Ctrl+R arms *all* tracks, Alt+R arms only the focused or selected tracks. Does that not cover it? 

Thanks for your effort David. The command is:

4 hours ago, murat k. said:

Arm Tracks

I thought I was clear but no problem. You may not seen an issue in that command because the issue can be felt especially on the big project files.

You can see the issue by creating only MIDI tracks in an empty project. Since the effect of the issue increases depending on the number of tracks, 1000 MIDI Tracks are suitable for to see the issue better.

When Auto Arm is enabled, you'll see recording a track starts instantly.

But when you try to record a track when Auto Arm is disabled, and you use Arm Tracks command to arm a track, it starts a calculation to prepare the track for the record and it takes a couple of seconds. This is the issue in the command and can be rectified by an optimization.

[David Baay]

34 minutes ago, murat k. said:

1000 MIDI Tracks are suitable for to see the issue better.

Notwithstanding that such a project would seem likely to be unmanageable in other respects, I  went ahead and tested with 1200 empty tracks (400 MIDI and 800 Audio) and saw very slight delay (less than 1 second) between arming a track with Alt+R and having the transport start rolling when R is hit immediately after arming. This delay seemed to correspond to a delay in the Arm button in the Track Inspector changing state to match the track.

Such a small delay seems quite tolerable to me. If you're seeing  a much longer delay than that, it may be related to your interface driver or something else system-specific.

 

[c0d3r]

6 hours ago, murat k. said:

Auto Arm feature we use for MIDI/Instrument Tracks

Where is an Auto Arm Feature?
Can i create several MIDI/Instrument Tracks and mark it as Auto Arm? And switch with mouse or arrow keys between the autoarmed tracks while recording?
I don´t find that feature.

[David Baay]

There is an option to "Allow MIDI Recording without an Armed Track" in Preferences > MIDI > Playback and Recording. The currently focused track is effectively 'auto-armed'.

Edited October 31, 2022 by David Baay

[murat k.]

Thanks for trying it out.

If it is

24 minutes ago, David Baay said:

(less than 1 second)

yeah it is not a problem actually.

23 minutes ago, David Baay said:

Such a small delay seems quite tolerable to me. If you're seeing  a much longer delay than that, it may be related to your interface driver or something else system-specific.

It seems that latency is related to the system speed indeed. If it was related to the interface driver it should've happened with other situations.

How does that command works I don't know but pressing record button works instantly, Auto-Arm with MIDI tracks works instantly as well. So there seems to be no reason why this command shouldn't work as fast as they do.

Apparently Arm Tracks command is making unnecesarry calculations. An optimization would not be bad at all so that it runs at adequate speed on every system configuration.

[scook]

Bear in mind MIDI data is written directly into the project file which the DAW has open. There is very little setup time needed to create MIDI clips.

Audio clips, on the other hand, are written as separate files.  Their setup time is much more system dependent than MIDI.

[murat k.]

11 minutes ago, scook said:

Bear in mind MIDI data is written directly into the project file which the DAW has open. There is very little setup time needed to create MIDI clips.

Audio clips, on the other hand, are written as separate files. The setup time is system dependent.

Thanks for the reminder Steve.

The problem here is that the command takes into the calculation all the tracks, even though they are not needed. So there is nothing to do with creating an audio file on the drive. Also same command cause latency with the MIDI and the Instrument tracks as well.

[David Baay]

Another factor may be that when you use a shortcut, the program has to both process that keystroke through the keybinding logic with reference to the current context (i.e. which element of which view has focus) and also check which of the 1000 tracks is selected and should be affected by the action. When you click the button in the track directly, you're eliminating all of that work. 

 

[murat k.]

5 hours ago, David Baay said:

Another factor may be that when you use a shortcut, the program has to both process that keystroke through the keybinding logic with reference to the current context (i.e. which element of which view has focus) and also check which of the 1000 tracks is selected and should be affected by the action. When you click the button in the track directly, you're eliminating all of that work. 

This is the factor. The command bound to the key scans the whole project to find the selected track(s).

The command needs to see focused track, the selected tracks if there is any, without scanning all tracks. For now it doesn't.