Audacity

›

audacity-devel

EXPERIMENTAL_MODULES

67 Messages

1 2 3 4

Martyn Shaw-2

EXPERIMENTAL_MODULES

Reply Threaded

Hi there

I note that I took EXPERIMENTAL_MODULES out of the vcproj file back on
15/5/2008, perhaps wrongly, and I can't really remember why.

I see it was enabled on 20/5/2008 in Experimental.h, but I don't see
any reference as to why.

As a result we have in there:

// These are all quite OK for Beta builds.
#define EXPERIMENTAL_MODULES
#ifdef EXPERIMENTAL_MODULES
// These are all quite OK for Beta builds.
#define EXPERIMENTAL_THEMING
#define EXPERIMENTAL_THEME_PREFS
#define EXPERIMENTAL_SMART_RECORD
#endif
(can I indent it like that?)

I'm not sure that was ever the intention. And they are enabled for
all builds (I think).

We were trying to get dll compilation and LoadModules working, using
mod-script-pipe as an example of that, weren't we? In the process we
enabled EXPERIMENTAL_THEMING and EXPERIMENTAL_SMART_RECORD, neither of
which are really ready. EXPERIMENTAL_SMART_RECORD doesn't even work
any more (and I'd forgotten that I'd committed it, when the guy I
wrote it for asked me about it the other day I told him it was lost
forever!)

So I propose that #define EXPERIMENTAL_MODULES should be removed from
Experimental.h, or at least EXPERIMENTAL_MODULES be defined only for
debug builds.

What do you think?

TTFN
Martyn

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Vaughan Johnson

Re: EXPERIMENTAL_MODULES

Reply Threaded

I think modules and theming are working, per Leland, so for the time
being, comment out only EXPERIMENTAL_SMART_RECORD (which should
eventually fold into the existing "smart record" class!).

But maybe we're sufficiently committed to modules and themes to
un-"experimental" them?

- V

Martyn Shaw wrote:

> Hi there
>
> I note that I took EXPERIMENTAL_MODULES out of the vcproj file back on
> 15/5/2008, perhaps wrongly, and I can't really remember why.
>
> I see it was enabled on 20/5/2008 in Experimental.h, but I don't see
> any reference as to why.
>
> As a result we have in there:
>
> // These are all quite OK for Beta builds.
> #define EXPERIMENTAL_MODULES
> #ifdef EXPERIMENTAL_MODULES
> // These are all quite OK for Beta builds.
> #define EXPERIMENTAL_THEMING
> #define EXPERIMENTAL_THEME_PREFS
> #define EXPERIMENTAL_SMART_RECORD
> #endif
> (can I indent it like that?)
>
> I'm not sure that was ever the intention. And they are enabled for
> all builds (I think).
>
> We were trying to get dll compilation and LoadModules working, using
> mod-script-pipe as an example of that, weren't we? In the process we
> enabled EXPERIMENTAL_THEMING and EXPERIMENTAL_SMART_RECORD, neither of
> which are really ready. EXPERIMENTAL_SMART_RECORD doesn't even work
> any more (and I'd forgotten that I'd committed it, when the guy I
> wrote it for asked me about it the other day I told him it was lost
> forever!)
>
> So I propose that #define EXPERIMENTAL_MODULES should be removed from
> Experimental.h, or at least EXPERIMENTAL_MODULES be defined only for
> debug builds.
>
> What do you think?
>
> TTFN
> Martyn
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Audacity-devel mailing list
> Audacity-devel@...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

Re: EXPERIMENTAL_MODULES

Reply Threaded

| From Vaughan Johnson <vaughan@...>
| Tue, 27 May 2008 19:55:23 -0700
| Subject: [Audacity-devel] EXPERIMENTAL_MODULES
> I think modules and theming are working, per Leland, so for the time
> being, comment out only EXPERIMENTAL_SMART_RECORD (which should
> eventually fold into the existing "smart record" class!).
>
>
> But maybe we're sufficiently committed to modules and themes to
> un-"experimental" them?

Unfortunately I added theming and smart record to "new features"
in the 1.3.6a1 README.txt, as I thought we might be close to
"release", and this had not then arrived. But either can be removed
of course.

I do think there is sufficient user interest in theming/skins to
include it, and "un-experiment" it and try to make it more useful.
Had this been other than an internal release, I might have felt
otherwise, as it is at the moment.

Martyn, I'd add that there is also considerable user interest in a
pause on recording feature, and I do have a previous Beta where
it seems to work perfectly, as far as its features go. I do hope you
may be able to develop it further.

Thanks

Gale

>
> Martyn Shaw wrote:
> > Hi there
> >
> > I note that I took EXPERIMENTAL_MODULES out of the vcproj file back on
> > 15/5/2008, perhaps wrongly, and I can't really remember why.
> >
> > I see it was enabled on 20/5/2008 in Experimental.h, but I don't see
> > any reference as to why.
> >
> > As a result we have in there:
> >
> > // These are all quite OK for Beta builds.
> > #define EXPERIMENTAL_MODULES
> > #ifdef EXPERIMENTAL_MODULES
> > // These are all quite OK for Beta builds.
> > #define EXPERIMENTAL_THEMING
> > #define EXPERIMENTAL_THEME_PREFS
> > #define EXPERIMENTAL_SMART_RECORD
> > #endif
> > (can I indent it like that?)
> >
> > I'm not sure that was ever the intention. And they are enabled for
> > all builds (I think).
> >
> > We were trying to get dll compilation and LoadModules working, using
> > mod-script-pipe as an example of that, weren't we? In the process we
> > enabled EXPERIMENTAL_THEMING and EXPERIMENTAL_SMART_RECORD, neither of
> > which are really ready.
>
>
> *** EXPERIMENTAL_SMART_RECORD doesn't even work
> > any more (and I'd forgotten that I'd committed it, when the guy I
> > wrote it for asked me about it the other day I told him it was lost
> > forever!)
> >
>
>
> > So I propose that #define EXPERIMENTAL_MODULES should be removed from
> > Experimental.h, or at least EXPERIMENTAL_MODULES be defined only for
> > debug builds.
> >
>
> > What do you think?
> >
> > TTFN
> > Martyn
> >

Martyn Shaw-2

Re: EXPERIMENTAL_MODULES

Reply Threaded

Gale Andrews wrote:
> | From Vaughan Johnson <vaughan@...>
> | Tue, 27 May 2008 19:55:23 -0700
> | Subject: [Audacity-devel] EXPERIMENTAL_MODULES
>> I think modules and theming are working, per Leland, so for the time
>> being, comment out only EXPERIMENTAL_SMART_RECORD (which should
>> eventually fold into the existing "smart record" class!).

I've tidied up the EXPERIMENTAL_SMART_RECORD to work with later
changes, but it still doesn't have a 'pre-roll' feature, which I think
would be a lot of effort to implement (an a bit useful). I've left it
in as I think it's useful as-is. I don't know about the "smart
record" class.

>> But maybe we're sufficiently committed to modules and themes to
>> un-"experimental" them?

Why are 'modules' and 'themes' joined together here? Are they
related? I think not. 'Themes' should only be in any release if
there is a default 'as it was' theme, I think, as per Leland's post of
23/5/8..

"1) First priority is to make the default theme to be what it looks
like without theming enabled. We do not want to force the
experimental color scheme onto anyone."

We certainly shouldn't be lead by what's been provisionally posted in
the README.txt, as Gale said.

So leave them both in for now?

Martyn

> Unfortunately I added theming and smart record to "new features"
> in the 1.3.6a1 README.txt, as I thought we might be close to
> "release", and this had not then arrived. But either can be removed
> of course.
>
> I do think there is sufficient user interest in theming/skins to
> include it, and "un-experiment" it and try to make it more useful.
> Had this been other than an internal release, I might have felt
> otherwise, as it is at the moment.
>
> Martyn, I'd add that there is also considerable user interest in a
> pause on recording feature, and I do have a previous Beta where
> it seems to work perfectly, as far as its features go. I do hope you
> may be able to develop it further.
>
>
> Thanks
>
>
> Gale
>
>> Martyn Shaw wrote:
>>> Hi there
>>>
>>> I note that I took EXPERIMENTAL_MODULES out of the vcproj file back on
>>> 15/5/2008, perhaps wrongly, and I can't really remember why.
>>>
>>> I see it was enabled on 20/5/2008 in Experimental.h, but I don't see
>>> any reference as to why.
>>>
>>> As a result we have in there:
>>>
>>> // These are all quite OK for Beta builds.
>>> #define EXPERIMENTAL_MODULES
>>> #ifdef EXPERIMENTAL_MODULES
>>> // These are all quite OK for Beta builds.
>>> #define EXPERIMENTAL_THEMING
>>> #define EXPERIMENTAL_THEME_PREFS
>>> #define EXPERIMENTAL_SMART_RECORD
>>> #endif
>>> (can I indent it like that?)
>>>
>>> I'm not sure that was ever the intention. And they are enabled for
>>> all builds (I think).
>>>
>>> We were trying to get dll compilation and LoadModules working, using
>>> mod-script-pipe as an example of that, weren't we? In the process we
>>> enabled EXPERIMENTAL_THEMING and EXPERIMENTAL_SMART_RECORD, neither of
>>> which are really ready.
>>
>> *** EXPERIMENTAL_SMART_RECORD doesn't even work
>>> any more (and I'd forgotten that I'd committed it, when the guy I
>>> wrote it for asked me about it the other day I told him it was lost
>>> forever!)
>>>
>>
>>> So I propose that #define EXPERIMENTAL_MODULES should be removed from
>>> Experimental.h, or at least EXPERIMENTAL_MODULES be defined only for
>>> debug builds.
>>>
>>> What do you think?
>>>
>>> TTFN
>>> Martyn
>>>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Audacity-devel mailing list
> Audacity-devel@...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Vaughan Johnson

Re: EXPERIMENTAL_MODULES

Reply Threaded

Martyn Shaw wrote:

> Gale Andrews wrote:
>
>> | From Vaughan Johnson <vaughan@...>
>> | Tue, 27 May 2008 19:55:23 -0700
>> | Subject: [Audacity-devel] EXPERIMENTAL_MODULES
>>
>>> I think modules and theming are working, per Leland, so for the time
>>> being, comment out only EXPERIMENTAL_SMART_RECORD (which should
>>> eventually fold into the existing "smart record" class!).
>>>
>
> I've tidied up the EXPERIMENTAL_SMART_RECORD to work with later
> changes, but it still doesn't have a 'pre-roll' feature, which I think
> would be a lot of effort to implement (an a bit useful). I've left it
> in as I think it's useful as-is. I don't know about the "smart
> record" class.
>
>

It's called (drum roll) SmartRecordDialog and currently is only Timer
Record, but we had discussed on -devel for quite a while that it would
have other "smart" features, possibly combinable (e.g., record anything
above a certain level, for 6 hours tomorrow morning).

If not integrated, one or the other should be renamed to reduce
confusion. Gale suggested to me o/l calling yours "level-activated
recording" and I suggested "volume" or "amplitude" or "loudness" instead
of "level".

- V

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: EXPERIMENTAL_MODULES

Reply Threaded

OK, sorry about that, I had forgotten about our discussions back last
June/July. I have just re-read
http://www.nabble.com/RecordPauseOnSilence-td11271572.html#a11596665
to remind myself. I see my last response was 'I'm not ignoring this,
just waiting until after the next release to put some more thought
into it.' Well I forgot, it seems like this is the time.

There certainly is a naming confusion, which we can easily sort out
(see below).

I'm not sure that integration is the way to go. One reason is that
there isn't much to integrate! SmartRecordPrefs.cpp only sets a
couple of preferences, nothing else, the rest of the 'operations' are
in AudioIO. Another reason is that TimerRecord and
RecordPauseOnSilence are related (to recording) but orthogonal (that
is independent, you can do either one without the other).

I note that I put this as a new preference panel on James's suggestion
(originally I put it as part of AudioIOPrefs) , but I agree that there
are a number of 'recording' options now existing, and proposed, and no
one way to get at them.

I also think that 'Timer Record...' is not that discoverable on the
'Tracks' menu (I can never remember where it is).

So what about a new 'Record' menu item? (We don't have many menu
items, there's lots of space, people record a lot, I guess.) I'd put
it between 'View' and 'Tracks', but I'm open to suggestions.

It could have
Timer Record...
Pause on Silence...

and possibly (taken from Audio I/O prefs)
Channels... (wasn't that problem of 'record in stereo' noted
recently? I had to talk somebody through it just yesterday.)
Playthrough...

and then in the future
Record directly to... (wav, mps etc)

and probably (since some halfwit won't know what the big red button is
for)
Record

So yes, I (currently) think SmartRecordDialog.* should become
TimerRecordDialog.* and SmartRecordPrefs.* should become
RecordPauseOnSilence.* almost as per your Jul 10, 2007 post. Those
other things look orthogonal too, so a dialog to handle them all would
seem redundant.

TTFN
Martyn

Vaughan Johnson wrote:

> Martyn Shaw wrote:
>> Gale Andrews wrote:
>>
>>> | From Vaughan Johnson <vaughan@...> | Tue, 27 May 2008
>>> 19:55:23 -0700
>>> | Subject: [Audacity-devel] EXPERIMENTAL_MODULES
>>>
>>>> I think modules and theming are working, per Leland, so for the time
>>>> being, comment out only EXPERIMENTAL_SMART_RECORD (which should
>>>> eventually fold into the existing "smart record" class!).
>>>>
>>
>> I've tidied up the EXPERIMENTAL_SMART_RECORD to work with later
>> changes, but it still doesn't have a 'pre-roll' feature, which I think
>> would be a lot of effort to implement (an a bit useful). I've left it
>> in as I think it's useful as-is. I don't know about the "smart
>> record" class.
>>
>>
>
> It's called (drum roll) SmartRecordDialog and currently is only Timer
> Record, but we had discussed on -devel for quite a while that it would
> have other "smart" features, possibly combinable (e.g., record anything
> above a certain level, for 6 hours tomorrow morning).
>
> If not integrated, one or the other should be renamed to reduce
> confusion. Gale suggested to me o/l calling yours "level-activated
> recording" and I suggested "volume" or "amplitude" or "loudness" instead
> of "level".
>
> - V
>
>

Gale Andrews

Re: EXPERIMENTAL_MODULES

Reply Threaded

| From Martyn Shaw <martynshaw99@...>
| Sat, 31 May 2008 01:45:03 +0100
| Subject: [Audacity-devel] EXPERIMENTAL_MODULES
> I note that I put (Pause on Silence) as a new preference panel on
> James's suggestion (originally I put it as part of AudioIOPrefs)

I personally think it would more logically have gone in Audio I/O
Preferences, but lack of space could be a problem.

> I also think that 'Timer Record...' is not that discoverable on the
> 'Tracks' menu (I can never remember where it is).
>
> So what about a new 'Record' menu item? (We don't have many menu
> items, there's lots of space, people record a lot, I guess.) I'd put
> it between 'View' and 'Tracks', but I'm open to suggestions.
>
> It could have
> Timer Record...
> Pause on Silence...

Can we move away from that title? It suggests pause is all it does.
I'd be very happy with "volume-activated recording" as per Vaughan's
modification of my suggestion. Or can you think of something that
covers both pausing and restarting?

> and possibly (taken from Audio I/O prefs)
> Channels... (wasn't that problem of 'record in stereo' noted
> recently? I had to talk somebody through it just yesterday.)

The hidden nature of setting channels has been something I've
been going on about for years, though as an alternative solution,
setting default to stereo (2 channels) would solve some of
the problem, I think.

> Playthrough...
>
> and then in the future
> Record directly to... (wav, mps etc)
>
> and probably (since some halfwit won't know what the big red button is
> for) Record

We'd need to keep things so you can still do a timed recording which
pauses and restarts according to level. I just did it and it seemed to work
well.

My reaction to having all this in a menu is that it sounds more akin to
a "recording toolbar", and might be easier navigated as such rather
than through a number of sub-menus. I'm not sure if that would mean
duplicating recording device from preferences in such a toolbar. It
could conceivably be an Audio I/O toolbar, so replace Device Toolbar
altogther.

If we went down this road, we might want to include append-record?

All that said, I'm not yet convinced a Record Menu or Toolbar is the
way to go (short term anyway). Pause on Recording is IMO a preference
so that it can be used with append-record, timed record or normal record.
The two problems for me are 1) inaccessibility of channels 2) Timer
Record being fairly hard to find.

I always thought the recording channels selector should be part of
Device Toolbar. When we get other than stereo-only playback,
adding channels to Device Toolbar might make even more sense.
As for a better place for Timer Record, simply a separate Record
button with a clock on it, which launches the dialogue?

Gale

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

Re: EXPERIMENTAL_MODULES

Reply Threaded

Martyn Shaw wrote:
> So what about a new 'Record' menu item? (We don't have many menu
> items, there's lots of space, people record a lot, I guess.) I'd put
> it between 'View' and 'Tracks', but I'm open to suggestions.
>
I'd back a new menu, but possibly find a more general top-level-title so
more tape-recorder-control waifs and strays can get onto it?

Consider the case of loop-play (shift plus play). I at one stage saw
the smart-record features as being handled in a similar way, called up
from the record button (shift plus record). We could still do that too,
but it isn't half as discoverable as a menu item for smart record or for
loop play. A menu makes sense. In the future we could have many
variants on both play and record. It's already starting to happen,
play, loop-play, play-at speed, play-to-next-marker. Same is possible
with record. Record, record on trigger, record until.... We might also
have variants of pause with different triggers and timers.

I don't have a good suggestion for a top level menu title that
encompasses both play and record. 'Audio' was the best I came up with,
and I suppose would do, but it's a bit too general.

--James.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

David Bailes-2

Re: EXPERIMENTAL_MODULES

Reply Threaded

Hi,

On 5/31/08, James Crook <crookj@...> wrote:
> I don't have a good suggestion for a top level menu title that
> encompasses both play and record. 'Audio' was the best I came up with,
> and I suppose would do, but it's a bit too general.

how about control. I know there's already a control toolbar, but ...

David.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Richard Ash (audacity-help)

Re: EXPERIMENTAL_MODULES

Reply Threaded

On Fri, 2008-05-30 at 01:09 +0100, Martyn Shaw wrote:
> Why are 'modules' and 'themes' joined together here? Are they
> related?
To quote:
// JKC July-2007: I'm temporarily using EXPERIMENTAL_MODULES to
// switch on all experimental features that I am interested in.

Which with hindsight may have been a mistake, as modules has come out of
experimental rather sooner than either of the other two. So there is no
particular technical reason to enable either Themes or Smart Record at
this point.

> 'Themes' should only be in any release if
> there is a default 'as it was' theme, I think, as per Leland's post of
> 23/5/8..

> "1) First priority is to make the default theme to be what it looks
> like without theming enabled. We do not want to force the
> experimental color scheme onto anyone."
Is there a way to achieve this, short of going through manually building
a theme file that matches the old appearance? I tried to use the "return
to defaults" button but it didn't appear to do anything.

> So leave them both in for now?
Because of the above I have themes turned off locally if I actually want
to do anything with audacity, because the lack of contrast and small
buttons are otherwise a major pain.

Richard

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

Re: EXPERIMENTAL_MODULES

Reply Threaded

Richard Ash wrote:
>
>> "1) First priority is to make the default theme to be what it looks
>> like without theming enabled. We do not want to force the
>> experimental color scheme onto anyone."
>>
> Is there a way to achieve this, short of going through manually building
> a theme file that matches the old appearance? I tried to use the "return
> to defaults" button but it didn't appear to do anything.
>
Update your Experimental.h to the latest version (just checked in) which
changes one #define. Theme prefs are present, but the default theme is
back to the old one. The data is all there in ThemeAsCeeCode.cpp. The
#ifdef in that file gives two versions. The old version binary data is
already there and so doesn't have to be built up manually.

(anyone who prefers the current theme should use theme prefs to save it,
before updating from CVS)

> Because of the above I have themes turned off locally if I actually want
> to do anything with audacity, because the lack of contrast and small
> buttons are otherwise a major pain.
>
Which buttons are smaller than they were? One of the limitations of
theming as it currently is is that the icons are a fixed size!

--James.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: EXPERIMENTAL_MODULES

Reply Threaded

Hi Gale!

Gale Andrews wrote:
...

>> Pause on Silence...
>
> Can we move away from that title? It suggests pause is all it does.
> I'd be very happy with "volume-activated recording" as per Vaughan's
> modification of my suggestion. Or can you think of something that
> covers both pausing and restarting?

I've tried googling the possibilities listed in Vaughan's post, and
only "level activated recording" got hits (388). Of course "voice
activated recording" got 168 times as many hits (65,200), but that's
overly restrictive. "Sound activated recording" (6000), how about that?

>> and possibly (taken from Audio I/O prefs)
>> Channels... (wasn't that problem of 'record in stereo' noted
>> recently? I had to talk somebody through it just yesterday.)
>
> The hidden nature of setting channels has been something I've
> been going on about for years, though as an alternative solution,
> setting default to stereo (2 channels) would solve some of
> the problem, I think.

I've seen 100s of files where somebody has plugged in a mike in, hit
record (not on Audacity, other software), got a stereo track to record
into by default, and (depending on hardware) recorded on either left,
right, both or both with one inverted; all recoverable situations
(with some effort, and an ability to learn). Recording into mono
isn't always recording, that is, not always recoverable. So for that
reason alone I support your idea that we should record into 2 channels
by default.

But could we still change the pref by a menu entry? Or is that
against some UI guidelines?

>> Playthrough...
>>
>> and then in the future
>> Record directly to... (wav, mps etc)
>>
>> and probably (since some halfwit won't know what the big red button is
>> for) Record
>
> We'd need to keep things so you can still do a timed recording which
> pauses and restarts according to level. I just did it and it seemed to work
> well.

I am not proposing changing the behaviour. They would still remain
independent, that's the point.

> My reaction to having all this in a menu is that it sounds more akin to
> a "recording toolbar", and might be easier navigated as such rather
> than through a number of sub-menus. I'm not sure if that would mean
> duplicating recording device from preferences in such a toolbar. It
> could conceivably be an Audio I/O toolbar, so replace Device Toolbar
> altogther.

Another / a bigger toolbar? I'm not sure I'd want that much
screen-estate (24,300) being taken up with something I might not use
that often.

> If we went down this road, we might want to include append-record?

Sure, on a menu. Remind me, is that a keyboard shortcut for something
without a menu item?

> All that said, I'm not yet convinced a Record Menu or Toolbar is the
> way to go (short term anyway). Pause on Recording is IMO a preference
> so that it can be used with append-record, timed record or normal record.
> The two problems for me are 1) inaccessibility of channels 2) Timer
> Record being fairly hard to find.

A new menu would make Timer Record easy to find, and 'sound activated
record' (6, but I'd like it shorter)) could be accessible both ways,
menu and prefs?

...
> As for a better place for Timer Record, simply a separate Record
> button with a clock on it, which launches the dialogue?

No! See 'screen-estate' above!

TTFN
Martyn

>
> Gale
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

Re: EXPERIMENTAL_MODULES

Reply Threaded

| From James Crook <crookj@...>
| Sat, 31 May 2008 18:31:38 +0100
| Subject: [Audacity-devel] EXPERIMENTAL_MODULES

> Richard Ash wrote:
> >
> >> "1) First priority is to make the default theme to be what it looks
> >> like without theming enabled. We do not want to force the
> >> experimental color scheme onto anyone."
> >>
> > Is there a way to achieve this, short of going through manually building
> > a theme file that matches the old appearance? I tried to use the "return
> > to defaults" button but it didn't appear to do anything.
> >
> Update your Experimental.h to the latest version (just checked in) which
> changes one #define. Theme prefs are present, but the default theme is
> back to the old one. The data is all there in ThemeAsCeeCode.cpp.

Sorry I'm a bit confused as I could not find that file, did you mean
ThemeAsCeeCode.h in the settings folder?

> The #ifdef in that file gives two versions. The old version binary data is
> already there and so doesn't have to be built up manually.
>
> (anyone who prefers the current theme should use theme prefs to save it,
> before updating from CVS)

I did that by "Save Theme Cache" (or did you mean "Output Sorcery")?
If I reload that cache in Audacity rebuilt from updated CVS, the Track Panel
is not quite the same colour (grey for selected, buff for non-selected) which
means the contrast problem there is now worse. Am I missing something?

Gale

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

Re: EXPERIMENTAL_MODULES

Reply Threaded

| From Martyn Shaw <martynshaw99@...>
| Sun, 01 Jun 2008 00:39:02 +0100
| Subject: [Audacity-devel] EXPERIMENTAL_MODULES

> Gale Andrews wrote:
> >> Pause on Silence...
> >
> > Can we move away from that title? It suggests pause is all it does.
> > I'd be very happy with "volume-activated recording" as per Vaughan's
> > modification of my suggestion. Or can you think of something that
> > covers both pausing and restarting?
>
> I've tried googling the possibilities listed in Vaughan's post, and
> only "level activated recording" got hits (388). Of course "voice
> activated recording" got 168 times as many hits (65,200), but that's
> overly restrictive. "Sound activated recording" (6000), how about that?

Better than "pause on silence" to me, but I don't like it as much
as "volume activated recording" because that describes what
specific characteristic of the input is the trigger. I'm trying to
think of something with the word "Record" first, such as "Record
on input". I've also thought of "signal activated recording" which
has two hits! Any support for "Signal Record" (which might
complement "Timer Record")? I have not got any other thoughts for
now.

>
> >> and possibly (taken from Audio I/O prefs)
> >> Channels... (wasn't that problem of 'record in stereo' noted
> >> recently? I had to talk somebody through it just yesterday.)
> >
> > The hidden nature of setting channels has been something I've
> > been going on about for years, though as an alternative solution,
> > setting default to stereo (2 channels) would solve some of
> > the problem, I think.
>
> I've seen 100s of files where somebody has plugged in a mike in, hit
> record (not on Audacity, other software), got a stereo track to record
> into by default, and (depending on hardware) recorded on either left,
> right, both or both with one inverted; all recoverable situations
> (with some effort, and an ability to learn). Recording into mono
> isn't always recording, that is, not always recoverable. So for that
> reason alone I support your idea that we should record into 2 channels
> by default.

I'd accept that mono default is generally more suitable for microphone
recording. My main reason for preferring stereo as default is based on
the seemingly endless number of Windows users who want to record
stereo mix from the internet, many of whom then can't find how to switch
on stereo recording in Audacity. Your reasoning seems to add weight to
that, also given increasing numbers of stereo USB microphones on the
market.

> But could we still change the pref by a menu entry? Or is that
> against some UI guidelines?

Having preference-changing items in a menu is part of my reservation
about using a menu. Of the items you mentioned, Pause on Silence,
Channels and Playthrough are all preferences.

>
> > My reaction to having all this in a menu is that it sounds more akin to
> > a "recording toolbar", and might be easier navigated as such rather
> > than through a number of sub-menus. I'm not sure if that would mean
> > duplicating recording device from preferences in such a toolbar. It
> > could conceivably be an Audio I/O toolbar, so replace Device Toolbar
> > altogther.
>
> Another / a bigger toolbar? I'm not sure I'd want that much
> screen-estate (24,300) being taken up with something I might not use
> that often.

I was probably a bit wooly when I said "toolbar", at least I don't think
it would (by default) behave exactly like a current toolbar. What I had
in mind (without having thought in detail) was a kind of drop-down
accessed from next to the Record button, something like Richard
suggested a year ago. He talked of it in terms of a menu, but I'd see
it more as something like a floating preferences tab dialogue with
necessary buttons to start different "types" of recording if we wanted
to do that. This could even be extended to starting a recording by
checkboxes, for example check all the boxes and you get a timed
append-recording that pauses when the level drops away. I'd guess
that this dialogue would disappear when you started the recording
(with an option to keep it visible), and that if you wanted to record
in exactly the same way next time, you just hit the main record button
and the dialogue does not appear at all.

>
> > If we went down this road, we might want to include append-record?
>
> Sure, on a menu. Remind me, is that a keyboard shortcut for something
> without a menu item?

SHIFT + R is the append-record shortcut, but R and spacebar also don't
of course have menu items. As I've suggested before, one simple way to
make append-record more discoverable is to add it to the Record button
tooltip like we do for loop play - "Record (Shift for append-record)".

>
> > All that said, I'm not yet convinced a Record Menu or Toolbar is the
> > way to go (short term anyway). Pause on Recording is IMO a preference
> > so that it can be used with append-record, timed record or normal record.
> > The two problems for me are 1) inaccessibility of channels 2) Timer
> > Record being fairly hard to find.
>
> A new menu would make Timer Record easy to find, and 'sound activated
> record' (6, but I'd like it shorter)) could be accessible both ways,
> menu and prefs?

I think this is a drawback of putting Pause on Silence in the menu;
Timer Record seems a bit different to me as it really must end with a
"record" command to make any sense, but that is not true of
Pause on Silence or even append recording.

> > As for a better place for Timer Record, simply a separate Record
> > button with a clock on it, which launches the dialogue?
>
> No! See 'screen-estate' above!

Well, some users do want a special button for it (even knowing
where to find it in the menu) and I'd expect more people to do so
when 1.4.0 comes out given the interest in recording "stereo mix".
Some even want a special button for loop-play(!).

There would seem to be room both at "preferences-cleared" opening
size and when maximised, if we do ever need to an extra button
in Control Toolbar for any reason. I can easily see those who never do
timed recording might object to two record buttons. I also agree
Timer Record in a "Record" menu is an easy quick way to make
it more discoverable, but I wonder if at present there are any other
items with a really strong case to join it in the menu.

Gale

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Richard Ash (audacity-help)

Re: EXPERIMENTAL_MODULES

Reply Threaded

On Sat, 2008-05-31 at 18:31 +0100, James Crook wrote:
> Update your Experimental.h to the latest version (just checked in) which
> changes one #define. Theme prefs are present, but the default theme is
> back to the old one. The data is all there in ThemeAsCeeCode.cpp. The
> #ifdef in that file gives two versions. The old version binary data is
> already there and so doesn't have to be built up manually.
Sorted, thanks.

> > Because of the above I have themes turned off locally if I actually want
> > to do anything with audacity, because the lack of contrast and small
> > buttons are otherwise a major pain.
> >
> Which buttons are smaller than they were? One of the limitations of
> theming as it currently is is that the icons are a fixed size!

I'm talking about the record/play buttons. They aren't located any
closer together, but I get a smaller (about 2/3 size) circular button in
the middle of a large grey square the same size as a normal button. So I
get half as much space to click in and no screen estate saving.

Richard

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

Re: EXPERIMENTAL_MODULES

Reply Threaded