Is there any progress to loosen the Timer Record lockout?

[Emerogork]

I set Timer Record and while it is counting down to start, I realize that an icon is under the Audacity window. I cannot get to it as I cannot move the window.

I have to end the timer-Record setting, move the window, move the icon, then restart the timer record. It takes about 20 keystrokes.

There may be some was through windows/dos to get to the icon but the problem doesn’t end there.

If I neglect to enable the audio meter to see the volume levels, I am locked out there too. Guess what? 20+ keystrokes again… If the music was being recorded, I would have to decide between continuity of the audio track VS use of that icon.

When the Timer Record is set and I am locked out, I cannot change the audio levels or make notes using B.

I have seen this for years and know that it has been discussed here. Is this going to change?

[waxcylinder]

A long time ago I wrote this proposal:

Timer Record Improvements #2407

Timer Record Improvements

Sadly this has been closed by Muse as “planned for much later (Audacity 4.x), closing for now”

So you may see this in a later version of Audacity - but not in the immediate future.

Peter.

[LWinterberg]

It’s reasonably easy to make a timer record functionality using mod-script-pipe which simply fires a record event at a pre-set time and a stop event at another. Using such a script wouldn’t lock up Audacity’s UI at all.

Unfortunately neither me nor the rest of the team really has the capacity to work on this right now. Anyone with enough time and a bit of python knowledge should be able to though.

[steve]

I wrote a Python script that makes recordings with Audacity. It’s more than what is required here as it makes a series of recordings, exporting before starting the next recording, but it can easily be set to just make a single recording by setting the number of recordings to 1.

The default settings are in this part of the code:

# Configuration options.
# Overrides interactive options when 'USE_CONFIG = True'.
USE_CONFIG = False

CONFIG: dict = {'ext': 'mp3',         # Export format
                'fname': 'myaudio',   # Root file name
                'fpath': Path('~/Desktop/mytest'),  # Export directory
                'duration': 10.0,  # Duration of each recording (seconds)
                'rcount': 3        # Number of recordings
                }

Here’s the script: Sequential recording with Audacity with Python. · GitHub

[Emerogork]

I would like to know more about the complication of the lockout and coding thereof. Is the hardship of working on it a matter of getting down into the nitty gritty and finding locations to release the lock out for each and every issue? It would require knowing and working on each one. I can see that would be not-so-inviting of a project.

To simplify the quest, can it be released for all tasks at the risk of having a project at great risk to itself? If that is the case, then I would be willing to take that risk and run it in an experimental environment.

OTOH, maybe I just don’t understand the issue… (-:

[LWinterberg]

I mean, if you want to take a stab at it, feel free to. It may be as easy as just telling the timer window to not be a modal, it may be as hard as uncoupling large parts of the internals. I’m a designer, not a programmer, so I don’t know the intricacies here.

The reason the issue got put into the “far future” bucket is that there are tons of more pressing issues, and, as pointed out by steve, there’s an alternative implementation that bypasses Audacity’s internals completely.

[waxcylinder]

James Crook’s take on this back in 2019, when he was considering taking on this mini-project give s some interesting insight into how this might be approached. It’s on the Talk page of the original Wiki proposal that I wrote:
https://wiki.audacityteam.org/wiki/Talk:Proposal_Timer_Record_Improvements_Phase-2

=========================================================================
There he wrote:
James 22Mar19:

I looked at working on this proposal at the start of 2.3.2. I found that it would be complex to implement if we had very specific choices of what was allowed ‘during timer record’ and what was not. Example: During waiting for a recording should we be allowed to change audio device, for example? Probably yes, but that takes time for some devices - and recording could attempt to start during a device change. Hard to implement that right.

I’ve decided the proposal needs more work, if it is me coding it. I’ve some suggestions:

Timer Record is a data entry screen. It can be opened at any time. It is modeless!
There is a button ‘Arm’ on it.
When Arm is down timer record is active and the normal Audacity GUI is locked out.
When Arm up, the normal Audacity GUI is active, and timer record will not start or stop recording.

In this way, you can arm/disarm timer record at any time, to get on with all your normal activity. Nothing is disabled when you have timer record disabled. You could, for example, after timer record has started recording, disarm timer record (recording continues), adjust levels, adjust the end time, and re-arm timer record, leaving it to finish off the recording at its new end time.

The current prohibition on timer record when there are unsaved changes would change.

A check box, checked by default, would enable close to current behaviour.
You could not arm a recording-start if there were unsaved changes. The dialog would show that ‘Unsaved Changes’ and ‘Arm’ button greyed out…
If in timer recording, a disarm would prompt with an ‘Are you sure?’ dialog.

Unchecking the check box, and you could proceed without those warnings / checks.

The current progress dialog would be integrated in the TimerRecord dialog, rather than be separate. As we can now return from the progress dialog to the timer record set up dialog, making them one is visually better.

=========================================================================

I suspect that James did not think that it was :

" as easy as just telling the timer window to not be a modal"

as otherwise he would likely have done just that - but like LWinterberg I am not (well not for a very long time anyway) a programmer - I only look at Audacity from the outside, from a user and UX perspective.

Peter.

[waxcylinder]

I’ve just been discussing with James whether or not it would be " as easy as just telling the timer window to not be a modal"

His thoughts are:

If I recall correctly the lock out of normal user interface was to prevent things that would disrupt timer record, or that would be disrupted by timer record starting.

For example, you don’t want an unsaved project in Audacity at 7:30PM when your timer recording starts, because then timer record would have to save it, and it might require user interaction.

If you don’t care about that kind of thing, then yes, making it non modal would work.

Sadly I do care about that sort of thing - so one would ideally need to build in safeguards for that, and that adds layers of complication.

Peter.