Re: [Audacity-devel] EXPERIMENTAL_MODULES
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Vaughan J. <va...@au...> - 2008-06-04 01:25:43
|
Thanks, Martyn. I think this is a fine idea. Lots of audio apps have a "Transport" menu for the play/record/pause/etc controls. Not sure if that name is clear for noobs. When I suggested it a few years ago, consensus was to not do it, mostly on the basis of "too many menus", but I wasn't persuaded it's a bad idea. And I think having a portion of the menu being for Record and its specializations (e.g., Timer Record) and prefs makes a Transport menu more justified. Regarding Gale's objection to prefs in menus, I don't see that as a problem. For example, we have View > Show Clipping that persists across sessions (and Snap To should have been a checkable item when it was in a menu). It's quite typical for on/off prefs to be checkable menu items (thus the existence of wxMenuItem::Check, etc). So I think the Sound Activated Recording menu item should be checkable. It could either open a dialog to select the threshold and on/off (i.e., not be directly checkable but show the checkmark in the menu if on in the dialog), or the threshold setting could be a separate item, e.g., Sound Threshold... And I think it's okay to mirror them in the prefs dialog if we want to keep Channels and Playthrough there as well as put them in the menu. I agree that Channels could well go in the Device Toolbar, except it's off by default, so there goes the increased discoverability of having it in a menu. So, something like: Play Loop Play Pause Stop ----- Record Timer Record... Sound Activated Recording... Channels... Playthrough (checkable menu item) ----- Fast Forward Rewind I agree with the renames to TimerRecordDialog and SoundActivatedRecording (or whatever is decided). - Vaughan Martyn Shaw wrote: > 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 <va...@au...> | 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 > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > |