Audacity Forum

waxcylinder wrote:

Gale Andrews wrote:Reading between the lines I think you are suggesting people are dissuaded from using Timer Record when it might be more appropriate because it's less functional. Perhaps time for a new campaign "Proposal Timer Record Improvements" (for after 2.0)?

Ok IC - I'll try to find some time to knock up a draft.

Rough draft proposal can be viewed at: http://wiki.audacityteam.org/wiki/User: ... provements

WC

I'd settle for the existing one working. For the first time ever (and illustrated in another post) I tried to make a timed hour recording starting in fifteen minutes. I was recording a "real" FM radio, so no bitstreams crashes, connection failures or IP conflicts.

I never made it. The system kept insisting on recording for 25 hours and nothing I could do would stop it. As I recall, the day kept rolling to N+1.

"No [email protected]#$, I don't want that day!"

I just pressed Record and left. I came back in three hours and cut off everything I didn't need.

Koz

kozikowski wrote:I'd settle for the existing one working. For the first time ever (and illustrated in another post) I tried to make a timed hour recording starting in fifteen minutes. I was recording a "real" FM radio, so no bitstreams crashes, connection failures or IP conflicts.

I never made it. The system kept insisting on recording for 25 hours and nothing I could do would stop it. As I recall, the day kept rolling to N+1.

Im puzzled Koz - I use the Timer Record 3 times a week, every week, to record one-hour "real" FM radio broadcasts and on XP this does not give me the problem that you describe.

1) It is possible for the timer fields to exhibit somewhat "odd" behavior in that you can enter values in the hours/mins/secs that exceed the normal maxima that one would expect of 24/60/60. And in those cases Audacity seems to calculate the "intended time" from the value that you entered, so entering a high value in the "hour" field for example will cause the date field to increment and the hour field to increment by less than the value you typed. Similarly typing a "9" in the leftmost minute field will cause the timer to increment by one and a half minutes.

All very logical in a way, but I would expect the fields to be limited to their normal maximum levels of 24/60/60 (and certainly, if I was programming this, that is the way I would have implemented it).


2) Also somewhat odd is the way that the two digits in each of the entry fields are treated as separate entities rather than as a consolidated unit. For example: click on the left digit in the "minute" field and then use the up-arrow, you will see the time increments in ten-minute steps; while clicking on the right digit in the "minute" field and then using the up arrow will cause one minute increments - and you can keep on using that up-arrow ad infinitum it seems.

Once again all very logical (and maybe even useful to some folk) but I would prefer the simpler approach of having the pair of numbers in the data-entry fields working as a single number so the the up & down arrows always only increment and decrement by one.


All in all the Timer Record dialg box behavior all looks counter-intuitive in some ways to me and smacks of the programmer(s) trying to be too clever by far and not sticking to the KISS principle.


@Gale: is this a bug - and if so will you log it for us in bugzilla? Or do I need to add it to my Timer Record enhancement proposal? Or am I just plain wrong in my expectations?

Peter

kozikowski wrote:I'd settle for the existing one working. For the first time ever (and illustrated in another post) I tried to make a timed hour recording starting in fifteen minutes. I was recording a "real" FM radio, so no bitstreams crashes, connection failures or IP conflicts.

I never made it. The system kept insisting on recording for 25 hours and nothing I could do would stop it. As I recall, the day kept rolling to N+1.

"No [email protected]#$, I don't want that day!"

I just pressed Record and left. I came back in three hours and cut off everything I didn't need.

I can't see details in any other posts, so can you please link to the post or give steps to reproduce the problem 1, 2, 3...

There is an open "moonphase" bug 42, previously common on Windows but now not being reported "Timer Record carries on recording past the scheduled end, requiring force quit". One of the reported scenarios concerned Timer recordings that started before midnight and were scheduled to finish after midnight. Is that anything to do with it? If not, which control ("End Date and Time" and/or "Duration") changes day, and when does it change?

Did the system time change for daylight savings or so? Small system clock changes were suspected as a reason for bug 42 but never proved. But if the system clock is set back to before the recording start time, the recording will carry on indefinitely as per Bug 43. I don't think I ever tested the bug attached to that patch for fixing the bug 43 problem, but it did not reliably fix the bug 42 problem.

waxcylinder wrote:All in all the Timer Record dialg box behavior all looks counter-intuitive in some ways to me and smacks of the programmer(s) trying to be too clever by far and not sticking to the KISS principle.

@Gale: is this a bug - and if so will you log it for us in bugzilla? Or do I need to add it to my Timer Record enhancement proposal? Or am I just plain wrong in my expectations?

All the TimeText controls operate in the same way. Try setting Selection Toolbar to hh:mm:ss and incrementing or typing.

In fact, a few people have complained (for example) that if current time is 23:00:00 then in "End Date and Time" you type "02" in the hours spinbox without incrementing the date, the "02" input is ignored. But that would inevitably happen there and in "Start Date and Time" unless the TimeText control included days (which would be confusing) or unless Timer was programmed so that entering an hour value before the current hour automatically advanced the date. I think that's a Feature Request not a bug. It's never been recorded as an FR, but I have definitely seen this suggestion so I'll search to find out how many votes it should have.


Gale

smacks of the programmer(s) trying to be too clever by far and not sticking to the KISS principle.

In the US, we are forbidden to type the two letter designation for a state. Apparently "CA" is too much for us creative, left-brain types to manage, so a pull-down menu system has been created for us. It doesn't matter how complicated, odd, hard to type, non-intuitive, or difficult to spell the rest of the mailing address is, the state is always a pulldown.

My house has a zip-9 code. It's unique. That's the only address I need to get a letter. xxxxx-xxxx is the address of my door knob, exclusive of the rest of the address.

Tried any of these on a Mac? Mac has an "iCal" calendar-scheduler program which, and I'm being generous, is an abomination. I forced one radio program to work right once after much poking and prodding, I'm afraid to touch it. I would set it up properly for a recording and save and close it. Open it up later and the values changed. Sometimes the time values wouldn't match the graphic. I suspect it ran into the :59/:60 rollover problem, but it did it on a massively theatrical scale and was kind of fun to watch. "I wonder what it's going to do that I didn't intend this time?" Newer TV and radio programs wisely avoid using it.

There is one television schedule that demands respect. I'm not at home, but one company uses schedules that start very shortly before the hour and end very shortly after. After you get used to the funny graphics, you figure out it tells you where the real start of a program is and whether or not it plays past the hour barrier. The worst one is the local PBS station whose schedules includes a block labeled 9:00am in the middle of the graphic. If a show starts 2/3 of the way through the block, when does it start? Are you sure?

Somebody inflicted the Audacity Time Entry Module on us once and we've been stuck with it ever since. I can remember taking upward of 10 seconds to force the tone generator to generate only 5 seconds of tone. Can we take that module out and shoot it? We're big on guns in the US and I have friends in Texas.

No, I'm not going over the daylight savings time barrier. As I recall, I was sitting at 9:30AM intending to make a recording from 10am to 11am on Saturday. It could not be simpler. No 12/24 barrier, either. Every time I armed the timer, I got the message that the system was all set to capture my 25-hour long program. After struggling with it, I found that the date had rolled over. As I recall, I could not get it to roll back. I still have the screen grab on one of the machines.

What was that thing about dealing with insanity? Back away slowly and don't make any overtly threatening moves.

The only interactivity with the time windows should be to turn red if I screw up.

Do.
Not.
Help.
Me.

Koz

Gale Andrews wrote:All the TimeText controls operate in the same way. Try setting Selection Toolbar to hh:mm:ss and incrementing or typing ... I think that's a Feature Request not a bug. It's never been recorded as an FR, but I have definitely seen this suggestion so I'll search to find out how many votes it should have.

OK so it was "designed" that way and is therefore a FR and not a bug.

kozikowski wrote:Somebody inflicted the Audacity Time Entry Module on us once and we've been stuck with it ever since ... Can we take that module out and shoot it? We're big on guns in the US and I have friends in Texas.

I agree with Koz here and still maintain that in this particular respect the GUI implementation is a "programmer" implementation and not a "normal human being" interface (and I speak as an ex-programmer ) So I will try to work "improved spinner behavior" into my draft Proposal for Timer Record improvenemts (and i do note that spinner behavior also relates to the Selection ToolBar - thanks for catching that Gale) But I won't be holding my breath waiting for this particular FR - I suspect we are stuck with it the way it is now , but I'll be happy to be proved wrong ...

Peter

kozikowski wrote:Somebody inflicted the Audacity Time Entry Module on us once and we've been stuck with it ever since. I can remember taking upward of 10 seconds to force the tone generator to generate only 5 seconds of tone. Can we take that module out and shoot it?

Assuming you are referring to TimeText Controls (spinboxes) they were added to assist visually impaired users. It can be helpful and less RSI-inducive to increment the digits with arrow keys. even for sighted users.

When you open a generator without a selection, focus should be on the last non-zero digit, so type "05". Of course, some people want to just type "5" as in 1.2 and their votes are on Feature Requests, although nothing will come of them. The major problems though are that most generators do not remember their last time input once you exit Audacity, and have no way to default to other than seconds (if I ever get time I will put the latter on Bugzilla).

kozikowski wrote:No, I'm not going over the daylight savings time barrier. As I recall, I was sitting at 9:30AM intending to make a recording from 10am to 11am on Saturday. It could not be simpler. No 12/24 barrier, either. Every time I armed the timer, I got the message that the system was all set to capture my 25-hour long program. After struggling with it, I found that the date had rolled over. As I recall, I could not get it to roll back. I still have the screen grab on one of the machines.

Then please post the screenshot of the "message" you received. I am not on a Mac so I cannot replicate a problem, beyond the one I stated about having to increment the date in "End Date and Time" in order to set the end time therein.

Steps, assuming I was doing this at 09:30 today 16 Sep 2011:
1. Set start time to 10:00:00
2. Set end date to 17/09/2011 (for UK, I assume date display is Americanized for you)
3. Set end time to 11:00:00
4. Observe duration is 1 days 00:00:00
5. Press OK.

So what exactly goes wrong? I can't put what you wrote on Bugzilla; A developer would tell me it doesn't compute. It sounds as if you never got to start the recording, as far as I can tell. If so, exact steps 1,2, 3 are the order of the day.


Gale

I can't put what you wrote on Bugzilla;

Nobody expects you to. I'm perfectly clear I need to document and repeat this problem. That was the narrative of the right-brain operator trying Very Hard to make a simple timer recording before leaving the house. The left-brain engineer is fascinated that you can make such a simple operation so difficult.

I was entirely in Saturday morning, so the 24-hour time wasn't significant. Being ex-army, I'm conversant in either time. My cellphone is telling me it's 1324 hours.

Koz

@Koz, I thought you were actually on about the previously raised problem of intuitively setting a recording ending next day.

If you were just making an hour's recording that day starting half an hour later, I wonder if the last time you pressed OK on Timer Record you were experimenting with recording for a duration of a day or more?

The "duration" (in seconds) is what is saved. So I just went into Timer Record to try and do the "hour's recording starting in half an hour" and suddenly realised the End date was tomorrow because the Duration was 1 day 1 hour (from the last time I played with it). But I can see clearly enough that the duration is 1 day 1 hour.

I can see an issue that you can't type in the selected portion of the date boxes. It looks like the input (or some approximation of it) is accepted where you type, but it reverts when unselected.

If you use the "arrow down" widget to right of the date, or select the day portion of the date and use down arrow on the keyboard, there is a small bug here too; for each day you increment down, a second is knocked off the duration .

But none of this stuff is a disaster IMHO; if you just change the duration there aren't any problems that I can see.



Gale

Gale Andrews wrote: ... TimeText Controls (spinboxes) they were added to assist visually impaired users. It can be helpful and less RSI-inducive to increment the digits with arrow keys. even for sighted users.

When you open a generator without a selection, focus should be on the last non-zero digit, so type "05". Of course, some people want to just type "5" as in 1.2 and their votes are on Feature Requests, although nothing will come of them...

As I stated earlier I believe that a lot of the un-intuitive behavior of the spinboxes comes from the fact that there are two separate input numeric fields for each of the hh/mm/ss input boxes (one for tens and one for units). I think that it would be more intuitive if each of these were a single input field.

Advantages:
1) Users could just type the "5" rather than the "05" and then tab to the next field.
2) the up/down-arrows usage would be retained for VI users

Disadvantages:
1) more keystrokes required for up/down arrow users when numbers greater than 9 are required

Peter.

@Gale: thanks for the edits and adding the stuff on Timer Controls to my draft proposal, much appreciated.