Thread: [Audacity-devel] a small patch to add a little feature
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: William F. D. Jr. <wfd...@gm...> - 2008-04-07 19:02:10
Attachments:
patchfile
|
Hello, I've been "ripping" my phonograph records to digital, and part of the process involves using Audacity to cut a "side" up into "tracks". I had the following "itches" which I scratched: 1. I work using the command line (in xterms), so I tend to cd to a directory where I have wav files of the sides of an LP, and run audacity on a side, like so: "audacity side1.wav &". Audacity wants to remember some previous working directory, and I want it to use the CURRENT working directory as the default to store files. So I modified AudacityApp.cpp to set DefaultExportPath to `pwd` if the file argument is a ".wav" file. 2. I find the spaces between the songs by inspection, and then put the cursor at the end of the first track, and then "select start to cursort" and "export selection as WAV". Navigating to "select start to cursor" is not fast because of the nested menu and the difficulty of getting the mouse there. I added a menu choice that does both these functions, including a key-stroke shortcut (ctrl+h). I think the keystroke shortcut is very important due to the difficulty in navigating the nested menus. I find these two changes make a real improvement in my speed at cutting sides into tracks. I'm afraid you'll not like these patches because they are pretty narrowly focused, but I thought I'd submit them anyway. Bill Dudley P.S. My working version of this is built off of audacity 1.2.4 which is the current version on my Ubuntu edgy box. I re-did the patch using the latest development version, but I can't build it because it requires a newer gtk then I have available to me. So I cannot guarantee it will compile, but it's nearly trivial, hence that shouldn't be a show stopper. (I *think* I made the gtk api changes from gtk 2.4 to gtk 2.[68] correctly.) |
From: Gale A. <ga...@au...> - 2008-04-08 00:31:23
|
| From "William F. Dudley Jr." <wfd...@gm...> | Mon, 7 Apr 2008 15:02:04 -0400 | Subject: [Audacity-devel] a small patch to add a little feature > I've been "ripping" my phonograph records to digital, and part of the > process involves using Audacity to cut a "side" up into "tracks". > > I had the following "itches" which I scratched:<snip> > 2. I find the spaces between the songs by inspection, and then put the > cursor at the end of the first track, and then "select start to cursort" and > "export selection as WAV". Navigating to "select start to cursor" is not > fast because of the nested menu and the difficulty of getting the mouse > there. I added a menu choice that does both these functions, including > a key-stroke shortcut (ctrl+h). I think the keystroke shortcut is very > important due to the difficulty in navigating the nested menus. Thanks for writing. Three comments on your second issue above: 1) Many users would do the splitting and exporting with Export Multiple so for them, only one operation per side of the LP is needed. 2) There are at least two easy ways to select start to cursor: * do the operation in reverse by pressing HOME then SHIFT - CLICK at the end of the first LP track * with the cursor at the end of the first LP track, hold down SHIFT and press HOME. Hold down SHIFT then END selects cursor to end. So in a sense we have the shortcuts already but don't mention it (does it work on all platforms? I'm on Windows). 3) I'd think we could not tag on an export command to such a shortcut (what about someone wanting to run an effect on the selection?) Gale |
From: Vaughan J. <va...@au...> - 2008-04-08 01:33:54
|
Gale Andrews wrote: > | From "William F. Dudley Jr." <wfd...@gm...> > | > ... >> 2. I find the spaces between the songs by inspection, In addition to what Gale wrote, the Analyze > Silence Finder effect automates this. - V |
From: William F. D. Jr. <wfd...@gm...> - 2008-04-08 03:18:09
|
Gale, Vaughan, I know I'm just wasting my breath at this point, but I've already tried the automated methods, and find they don't work reliably. See my comments below: On 4/7/08, Vaughan Johnson <va...@au...> wrote: > Gale Andrews wrote: > > | From "William F. Dudley Jr." <wfd...@gm...> > > >> 2. I find the spaces between the songs by inspection, > > In addition to what Gale wrote, the Analyze > Silence Finder effect > automates this. > But tragically, it won't work on an album that fades from one cut to the next without intervening silence. Also, it will give a "false positive" on songs with a quiet bit in the middle. That's why I don't use the automated methods, they're not 100% reliable. If I'm going to all the trouble of "ripping" 1000 LPs to digital, I don't want 10% of them to be botched up. >> 3) I'd think we could not tag on an export command to such a shortcut >> (what about someone wanting to run an effect on the selection?) If I'm translating a WAV of a phonograph album into tracks to burn a CD, then I probably (certainly?) don't want to run any "effects" on a single track. The most I might want to do is amplify the entire side so that it is just at clipping at the largest peak. I'm just trying to migrate all my vinyl music to digital, not get artistic with it. And if you DO want to do an effect on a single track, well, then, DON'T USE this feature! >> 1) Many users would do the splitting and exporting with Export Multiple >> so for them, only one operation per side of the LP is needed. This feature has the undesired result effect of keeping the "silent" parts between tracks as part of the track. I'd rather start the track when the sound starts, and cut it off when it fades out, and let the inter-song gap on the CD take care of the silent bits. I'm not that in love with record surface noise that I actually want to listen to a digital rendition of it. You do realize that I meant this feature to be "optional, and in addition to" the other features in Audacity, i.e. nobody will be forced to use it? :-) I didn't see any complaints about making `pwd` the default Save directory. Does that mean you think it's useful? I know that I find Audacity's insistence on using the previous save directory EVEN IF IT NO LONGER EXISTS to be very annoying. Sometimes the dialog box with the complaint about the non-existance of the directory gets buried under something, and then, guess what, it looks for all the world like Audacity has locked up, because it won't respond until you find the buried dialogue box and acknowledge it. >> * with the cursor at the end of the first LP track, hold down SHIFT >> and press HOME. Hold down SHIFT then END selects cursor to end. >> So in a sense we have the shortcuts already but don't mention it >> (does it work on all platforms? I'm on Windows). Undocumented features might as well not exist. Turns out, it works in Linux, but you'd have to study the source code harder than I did to find it. I just checked, it isn't in the Help that comes with 1.2.4 (or at least, I couldn't find it). (And I can't run 1.3.x, gtk not sufficient for that in Ubuntu Edgy). Is there a magic undocumented keystroke to do "export selection as wav" ? Then I wouldn't have to patch the thing to fix the awkward UI for my purposes. In fact, a shortcut for each of the following two features: 1. set Export dir to `pwd` 2. export selection as wav would solve my problem 99%, now that I know about Shift-Home. Thanks both of you for your comments, Bill Dudley |
From: Gale A. <ga...@au...> - 2008-04-08 17:15:01
|
| From "William F. Dudley Jr." <wfd...@gm...> | Mon, 7 Apr 2008 23:18:16 -0400 | Subject: [Audacity-devel] a small patch to add a little feature > On 4/7/08, Vaughan Johnson <va...@au...> wrote: > > Gale Andrews wrote: > > >> 2. I find the spaces between the songs by inspection, > > > > In addition to what Gale wrote, the Analyze > Silence Finder effect > > automates this. > > > > But tragically, it won't work on an album that fades from one cut to the next > without intervening silence. Also, it will give a "false positive" on songs > with a quiet bit in the middle. That's why I don't use the automated > methods, they're not 100% reliable. If I'm going to all the trouble of > "ripping" 1000 LPs to digital, I don't want 10% of them to be botched up. Obviously Silence Finder won't work if the end of one song fades into another without silence, but false positives can be largely avoided by increasing the silence threshold and minimum duration of silence. It should still save a large proportion of the work, and you can see from the label flags and the waveform which flags might be questionable. > >> 3) I'd think we could not tag on an export command to such a shortcut > >> (what about someone wanting to run an effect on the selection?) > > If I'm translating a WAV of a phonograph album into tracks to burn a CD, > then I probably (certainly?) don't want to run any "effects" on a single track. > The most I might want to do is amplify the entire side so that it is > just at clipping > at the largest peak. I'm just trying to migrate all my vinyl > music to digital, not> get artistic with it. > > And if you DO want to do an effect on a single track, well, then, DON'T USE > this feature! What I was suggesting is that since many people split LP tracks with export multiple, relatively few people would go on from select start to cursor directly to export. So we might have a problem justifying the extra menu line for "Start to Cursor and Export as WAV\tCtrl+H" and the extra hotkey, given the (unadvertised) hotkey already there for "start to cursor", and given the increasing pressure we're likely to face on available hotkeys. To my mind, a hotkey for "export as WAV" would be more generally useful, but then there'd be pressure for "export as other formats". I'm not strictly a developer, though, so I'm just giving my view. > >> 1) Many users would do the splitting and exporting with Export Multiple > >> so for them, only one operation per side of the LP is needed. > > This feature has the undesired result effect of keeping > the "silent" parts between tracks as part of the track. I'd rather > start the track when the sound starts, and cut it off when it fades out, > and let the inter-song gap on the CD take care of the silent bits. > I'm not that in love with record surface noise that I actually want to > listen to a digital rendition of it. > You do realize that I meant this feature to be "optional, and in addition to" > the other features in Audacity, i.e. nobody will be forced to use it? :-) To some extent you can improve this by adjusting the label placement before silence ends, but the current Silence Finder is never going to do it as accurately as a human. Alex S Brown was working on an improved version that marked the beginning and end of tracks, so letting you export just the tracks rather than the silence inbetween, but when I last fiddled with it, it looked to me too inaccurate to be ready for release. Apart from that, my point is that relatively few people might use the suggested feature, so the case for using up a menu line and hotkey is less strong. > I didn't see any complaints about making `pwd` the default Save directory. > Does that mean you think it's useful? I know that I find Audacity's insistence > on using the previous save directory EVEN IF IT NO LONGER EXISTS to be > very annoying. Sometimes the dialog box with the complaint about the > non-existance of the directory gets buried under something, and then, guess > what, it looks for all the world like Audacity has locked up, because it won't > respond until you find the buried dialogue box and acknowledge it. I did not comment as I have no experience of trying to get Audacity to export in this way, but I know one or two people who do control Audacity from the command line who have asked for just this feature in the past. I did compile your modified audacity.app. If I did it right and (as seems the case) it does not affect GUI users being offered the last used directory, I've no objections. But it needs Richard or similar on Linux to comment. > >> * with the cursor at the end of the first LP track, hold down SHIFT > >> and press HOME. Hold down SHIFT then END selects cursor to end. > >> So in a sense we have the shortcuts already but don't mention it > >> (does it work on all platforms? I'm on Windows). > > Undocumented features might as well not exist. Turns out, it works in Linux, > but you'd have to study the source code harder than I did to find it. So if someone can confirm it works on Mac, I would be in favour of documenting this and adding SHIFT + HOME and SHIFT + END to the menu items. Are there any problems with this simple change? I assume adding it as a customisable key binding is a lot more work. > Is there a magic undocumented keystroke to do "export selection as wav" ? No, but on Linux and Windows you can use ALT, so ALT F E E ENTER in terms of Audacity 1.2.x (i.e. the underlined characters in the menus). Gale |
From: William F. D. Jr. <wfd...@gm...> - 2008-04-08 19:45:38
|
Gale, Thanks for you continued feedback. my comments below: On 4/8/08, Gale Andrews <ga...@au...> wrote: > > | From "William F. Dudley Jr." <wfd...@gm...> > > | Mon, 7 Apr 2008 23:18:16 -0400 > > | Subject: [Audacity-devel] a small patch to add a little feature > > > On 4/7/08, Vaughan Johnson <va...@au...> wrote: > > > Gale Andrews wrote: > > > > >> 2. I find the spaces between the songs by inspection, > > > > > > In addition to what Gale wrote, the Analyze > Silence Finder effect > > > automates this. > > > > > > > But tragically, it won't work on an album that fades from one cut to the next > > without intervening silence. Also, it will give a "false positive" on songs > > with a quiet bit in the middle. That's why I don't use the automated > > methods, they're not 100% reliable. If I'm going to all the trouble of > > "ripping" 1000 LPs to digital, I don't want 10% of them to be botched up. > > > Obviously Silence Finder won't work if the end of one song fades into > another without silence, but false positives can be largely avoided by > increasing the silence threshold and minimum duration of silence. > It should still save a large proportion of the work, and you can see > from the label flags and the waveform which flags might be questionable. > > > > >> 3) I'd think we could not tag on an export command to such a shortcut > > >> (what about someone wanting to run an effect on the selection?) > > > > If I'm translating a WAV of a phonograph album into tracks to burn a CD, > > then I probably (certainly?) don't want to run any "effects" on a single track. > > The most I might want to do is amplify the entire side so that it is > > just at clipping > at the largest peak. I'm just trying to migrate all my vinyl > > music to digital, not> get artistic with it. > > > > And if you DO want to do an effect on a single track, well, then, DON'T USE > > this feature! > > > What I was suggesting is that since many people split LP tracks with > export multiple, relatively few people would go on from select start to > cursor directly to export. So we might have a problem justifying the > extra menu line for "Start to Cursor and Export as WAV\tCtrl+H" > and the extra hotkey, given the (unadvertised) hotkey already there > for "start to cursor", and given the increasing pressure we're likely to > face on available hotkeys. > > To my mind, a hotkey for "export as WAV" would be more generally > useful, but then there'd be pressure for "export as other formats". I'm > not strictly a developer, though, so I'm just giving my view. I'd argue that "export to WAV" is a special case because if you're going to burn a CD, you need WAV files as source material. (I'm aware that other formats could be coerced into being read by k3b or something, but that would be extra work.) > > > > >> 1) Many users would do the splitting and exporting with Export Multiple > > >> so for them, only one operation per side of the LP is needed. > > > > This feature has the undesired result effect of keeping > > the "silent" parts between tracks as part of the track. I'd rather > > start the track when the sound starts, and cut it off when it fades out, > > and let the inter-song gap on the CD take care of the silent bits. > > I'm not that in love with record surface noise that I actually want to > > listen to a digital rendition of it. > > You do realize that I meant this feature to be "optional, and in addition to" > > the other features in Audacity, i.e. nobody will be forced to use it? :-) > > > To some extent you can improve this by adjusting the label placement > before silence ends, but the current Silence Finder is never going to do > it as accurately as a human. Alex S Brown was working on an improved > version that marked the beginning and end of tracks, so letting you > export just the tracks rather than the silence inbetween, but when I > last fiddled with it, it looked to me too inaccurate to be ready for > release. Apart from that, my point is that relatively few people might > use the suggested feature, so the case for using up a menu line and > hotkey is less strong. Unless it's as good as I am, I don't want to use it. Like I said, I only want to do this job once. (Actually I want to do it zero times, but then I wouldn't be able to listen to this music on "modern" equipment.) > > > > I didn't see any complaints about making `pwd` the default Save directory. > > Does that mean you think it's useful? I know that I find Audacity's insistence > > on using the previous save directory EVEN IF IT NO LONGER EXISTS to be > > very annoying. Sometimes the dialog box with the complaint about the > > non-existance of the directory gets buried under something, and then, guess > > what, it looks for all the world like Audacity has locked up, because it won't > > respond until you find the buried dialogue box and acknowledge it. > > > I did not comment as I have no experience of trying to get Audacity to > export in this way, but I know one or two people who do control Audacity > from the command line who have asked for just this feature in the past. > I did compile your modified audacity.app. If I did it right and (as seems > the case) it does not affect GUI users being offered the last used directory, > I've no objections. But it needs Richard or similar on Linux to comment. Thanks for giving it a whirl. I really appreciate your time on this. My code only sets the Export Directory if you give it a .wav file as an argument, so it should only affect command line users. > > > > >> * with the cursor at the end of the first LP track, hold down SHIFT > > >> and press HOME. Hold down SHIFT then END selects cursor to end. > > >> So in a sense we have the shortcuts already but don't mention it > > >> (does it work on all platforms? I'm on Windows). > > > > Undocumented features might as well not exist. Turns out, it works in Linux, > > but you'd have to study the source code harder than I did to find it. > > > So if someone can confirm it works on Mac, I would be in favour of > documenting this and adding SHIFT + HOME and SHIFT + END to the > menu items. Are there any problems with this simple change? I assume > adding it as a customisable key binding is a lot more work. > > > > > Is there a magic undocumented keystroke to do "export selection as wav" ? > > > No, but on Linux and Windows you can use ALT, so ALT F E E ENTER > in terms of Audacity 1.2.x (i.e. the underlined characters in the menus). This doesn't seem to work in Linux under KDE (i.e. Kubuntu). Alt-F pulls down the file menu, but no keystroke that I tried would move the highlight down off of "New". A working hot-key here would be priceless. Perhaps the Fn keys (F1, F2, . . . F12) ? Bill Dudley > > > > Gale > |
From: Richard A. <ri...@au...> - 2008-04-08 20:43:02
|
On Tue, 2008-04-08 at 15:45 -0400, William F. Dudley Jr. wrote: > > To my mind, a hotkey for "export as WAV" would be more generally > > useful, but then there'd be pressure for "export as other formats". I'm > > not strictly a developer, though, so I'm just giving my view. > > I'd argue that "export to WAV" is a special case because if you're going to > burn a CD, you need WAV files as source material. (I'm aware that other > formats could be coerced into being read by k3b or something, but that > would be extra work.) You can already assign a hotkey for Export Selection from the Keyboard section of the audacity preferences. I tend to use the ` key because it's next to tab and not one I'm likely to try and type in a label anywhere, but you can choose anything you like. I don't have a 1.2.x build in front of me, but I'm pretty sure that there is an "Export Selection As WAV" item in the keybinding list for 1.2.x (There certainly is an "Export Selection" item in the 1.3.x keybinding list, where format is chosen (stickly) in the export dialogue). Richard |
From: Gale A. <ga...@au...> - 2008-04-08 23:06:27
|
| From "William F. Dudley Jr." <wfd...@gm...> | Tue, 8 Apr 2008 15:45:16 -0400 | Subject: [Audacity-devel] a small patch to add a little feature > > Gale: > > To my mind, a hotkey for "export as WAV" would be more generally > > useful, but then there'd be pressure for "export as other formats". I'm > > not strictly a developer, though, so I'm just giving my view. > > William: I'd argue that "export to WAV" is a special case because if you're going to > burn a CD, you need WAV files as source material. (I'm aware that other > formats could be coerced into being read by k3b or something, but that > would be extra work.) > > Richard: I don't have a 1.2.x build in front of me, but I'm pretty sure that > there is an "Export Selection As WAV" item in the keybinding list for > 1.2.x (There certainly is an "Export Selection" item in the 1.3.x > keybinding list, where format is chosen (stickly) in the export > dialogue). 1.2.x does indeed have an unallocated key binding for Export Selection as WAV (thanks, Richard) if you go into Preferences > Keyboard. It is actually called simply "Export Selection As...". I still think it might be nice in current 1.3 to have (unallocated) bindings again for Export and Export Selection as (format), but I don't know how it could work for GUI users now the user has to select the required format in the generic dialogue. (In 1.3 there is no cascading menu from "Export As..." for the different formats). > > > >> 1) Many users would do the splitting and exporting with Export Multiple > > > >> so for them, only one operation per side of the LP is needed. > > > > > > This feature has the undesired result effect of keeping > > > the "silent" parts between tracks as part of the track. I'd rather > > > start the track when the sound starts, and cut it off when it fades out, > > > and let the inter-song gap on the CD take care of the silent bits. > > > I'm not that in love with record surface noise that I actually want to > > > listen to a digital rendition of it. > > > You do realize that I meant this feature to be "optional, and in addition to" > > > the other features in Audacity, i.e. nobody will be forced to use it? :-) > > > > > > To some extent you can improve this by adjusting the label placement > > before silence ends, but the current Silence Finder is never going to do > > it as accurately as a human. Alex S Brown was working on an improved > > version that marked the beginning and end of tracks, so letting you > > export just the tracks rather than the silence inbetween, but when I > > last fiddled with it, it looked to me too inaccurate to be ready for > > release. Apart from that, my point is that relatively few people might > > use the suggested feature, so the case for using up a menu line and > > hotkey is less strong. > > Unless it's as good as I am, I don't want to use it. Like I said, I > only want to do this job once. Can you make export multiple work under your system? You can allocate a hotkey for it in the 1.2 Keyboard Preferences, and in 1.2 you don't have any issues with being asked for "tags" for the files, which you would have to turn off in 1.3. > My code only sets the Export Directory if you give it a .wav file as > an argument, so it should only affect command line users. I've certainly made a note of what to do to make it work in 1.2.x if anyone asks again. We'd need some votes from others to commit it (and decide if it should do the same for all formats) assuming it works at the command line in 1.3. Gale |
From: William F. D. Jr. <wfd...@gm...> - 2008-04-09 00:56:34
|
my comments below: On 4/8/08, Gale Andrews <ga...@au...> wrote: > > | From "William F. Dudley Jr." <wfd...@gm...> > > | Tue, 8 Apr 2008 15:45:16 -0400 > > | Subject: [Audacity-devel] a small patch to add a little feature > > > > Gale: > > > > To my mind, a hotkey for "export as WAV" would be more generally > > > useful, but then there'd be pressure for "export as other formats". I'm > > > not strictly a developer, though, so I'm just giving my view. > > > > > William: I'd argue that "export to WAV" is a special case because if you're going to > > > burn a CD, you need WAV files as source material. (I'm aware that other > > formats could be coerced into being read by k3b or something, but that > > would be extra work.) > > > > > Richard: I don't have a 1.2.x build in front of me, but I'm pretty sure that > > > there is an "Export Selection As WAV" item in the keybinding list for > > 1.2.x (There certainly is an "Export Selection" item in the 1.3.x > > keybinding list, where format is chosen (stickly) in the export > > dialogue). > > > 1.2.x does indeed have an unallocated key binding for Export Selection > as WAV (thanks, Richard) if you go into Preferences > Keyboard. It > is actually called simply "Export Selection As...". I still think it might > be nice in current 1.3 to have (unallocated) bindings again for Export > and Export Selection as (format), but I don't know how it could work > for GUI users now the user has to select the required format in the > generic dialogue. (In 1.3 there is no cascading menu from "Export As..." > for the different formats). Well, learn something every day. Yes, this would work for me. I can deal with "two" keystrokes Shift-Home, Ctrl-` or something instead of what I'm using in my patched version, Ctrl-h. > > > > > > > >> 1) Many users would do the splitting and exporting with Export Multiple > > > > >> so for them, only one operation per side of the LP is needed. > > > > > > > > This feature has the undesired result effect of keeping > > > > the "silent" parts between tracks as part of the track. I'd rather > > > > start the track when the sound starts, and cut it off when it fades out, > > > > and let the inter-song gap on the CD take care of the silent bits. > > > > I'm not that in love with record surface noise that I actually want to > > > > listen to a digital rendition of it. > > > > You do realize that I meant this feature to be "optional, and in addition to" > > > > the other features in Audacity, i.e. nobody will be forced to use it? :-) > > > > > > > > > To some extent you can improve this by adjusting the label placement > > > before silence ends, but the current Silence Finder is never going to do > > > it as accurately as a human. Alex S Brown was working on an improved > > > version that marked the beginning and end of tracks, so letting you > > > export just the tracks rather than the silence inbetween, but when I > > > last fiddled with it, it looked to me too inaccurate to be ready for > > > release. Apart from that, my point is that relatively few people might > > > use the suggested feature, so the case for using up a menu line and > > > hotkey is less strong. > > > > Unless it's as good as I am, I don't want to use it. Like I said, I > > only want to do this job once. > > > Can you make export multiple work under your system? You can > allocate a hotkey for it in the 1.2 Keyboard Preferences, and in 1.2 > you don't have any issues with being asked for "tags" for the > files, which you would have to turn off in 1.3. When I saw that it wanted to save the surface noise between songs as part of the song, I wrote this feature off as not useful. > > > > My code only sets the Export Directory if you give it a .wav file as > > an argument, so it should only affect command line users. > > > I've certainly made a note of what to do to make it work in 1.2.x if > anyone asks again. We'd need some votes from others to commit it > (and decide if it should do the same for all formats) assuming it works > at the command line in 1.3. I hope you can pursue this, I expect all command line users will rejoice. Though they might wish that it sets the Save Dir and Export Dir if ANY filename is given on the command line. I may have been too specific when I wrote my version, but I was trying to make the minimum change possible. Bill Dudley > > > > Gale > |
From: Gale A. <ga...@au...> - 2008-04-09 06:36:54
|
| From "William F. Dudley Jr." <wfd...@gm...> | Tue, 8 Apr 2008 20:56:41 -0400 | Subject: [Audacity-devel] a small patch to add a little feature > Well, learn something every day. Yes, this would work for me. I can deal > with "two" keystrokes Shift-Home, Ctrl-` or something instead of what I'm > using in my patched version, Ctrl-h. The two shortcuts could each have only one keystroke, e.g. F11 for selecting start to cursor, and F12 for export selection to WAV. > > Can you make export multiple work under your system? You can > > allocate a hotkey for it in the 1.2 Keyboard Preferences, and in 1.2 > > you don't have any issues with being asked for "tags" for the > > files, which you would have to turn off in 1.3. > > When I saw that it wanted to save the surface noise between songs > as part of the song, I wrote this feature off as not useful. It's the Silence Finder that is dropping labels between songs. Export Multiple will be equally happy if you place labels at selection areas (or cursor points) exactly where you want them - use CTRL + B then type the name you want for the file in the label. Gale |
From: Gale A. <ga...@au...> - 2008-04-09 16:34:26
|
| From "William F. Dudley Jr." <wfd...@gm...> | Tue, 8 Apr 2008 20:56:41 -0400 | Subject: [Audacity-devel] a small patch to add a little feature > Well, learn something every day. Yes, this would work for me. I can deal > with "two" keystrokes Shift-Home, Ctrl-` or something instead of what I'm > using in my patched version, Ctrl-h. As SHIFT + HOME and SHIFT + END do work on Mac for "Select Start to Cursor" and "Select Cursor to End", I'd like to add the text of those shortcuts to Menus.cpp to save further confusion. This also makes these shortcuts appear in the Keyboard preferences. If you then change the binding to some other key, SHIFT + HOME and SHIFT + END still work in addition to the new binding, but that's true now. I'll make this change in a few days unless someone objects. Gale Gale |
From: Richard A. <ri...@au...> - 2008-04-09 20:20:09
|
On Wed, 2008-04-09 at 17:34 +0100, Gale Andrews wrote: > As SHIFT + HOME and SHIFT + END do work on Mac for "Select Start to > Cursor" and "Select Cursor to End", I'd like to add the text of those > shortcuts to Menus.cpp to save further confusion. This also makes > these > shortcuts appear in the Keyboard preferences. If you then change the > binding to some other key, SHIFT + HOME and SHIFT + END still work in > addition to the new binding, but that's true now. Seems a good idea - I suspect this is one of the things I learnt by assuming it would work unless I found it didn't, but having it visible is never a bad thing, especially from the point of view of putting it in the keyboard shortcuts list. I'm puzzled why they don't work like all the other key bindings (in terms of not disappearing when re-mapped), I presume they are handled somewhere independent in the code. Richard |
From: David B. <drb...@go...> - 2008-04-10 17:24:18
|
Hi Gale On 4/9/08, Gale Andrews <ga...@au...> wrote: > As SHIFT + HOME and SHIFT + END do work on Mac for "Select Start to > Cursor" and "Select Cursor to End", I'd like to add the text of those > shortcuts to Menus.cpp to save further confusion. This also makes these > shortcuts appear in the Keyboard preferences. If you then change the > binding to some other key, SHIFT + HOME and SHIFT + END still work in > addition to the new binding, but that's true now. I'll make this change in > a few days unless someone objects. Shift + home selects the audio in the selected tracks between time zero and the cursor. Shift + end selects the audio in the selected tracks between the cursor and end of the data in all the tracks. In contrast, from the edit menu: Select start to cursor selects the audio in the selected tracks between the start of data in the selected tracks and the cursor. Select cursor to end selects the audio in the selected tracks between the cursor and the end of the data in the selected tracks. David. |
From: David B. <drb...@go...> - 2008-04-10 20:00:33
|
revised version. On 4/10/08, David Bailes <drb...@go...> wrote: > Shift + home selects the audio in the selected tracks between time > zero and the cursor. > Shift + end selects the audio in the selected tracks between the > cursor and end of the data in all the tracks. > > In contrast, from the edit menu: > Select start to cursor selects the audio in the selected tracks > between the start of data in the selected tracks and the cursor. > Select cursor to end selects the audio in the selected tracks between > the cursor and the end of the data in the selected tracks. This is better: Shift + home selects a time range from time zero to the cursor. Shift + end selects a time range from the cursor to the end of all the tracks. In contrast, from the edit menu: Select start to cursor selects a time range from the start of the data in the selected tracks to the cursor. Select cursor to end selects a time range from the cursor to the end of the data in the selected tracks. David. |
From: Gale A. <ga...@au...> - 2008-04-11 06:40:50
|
| From "David Bailes" <drb...@go...> | Thu, 10 Apr 2008 20:59:40 +0100 | Subject: [Audacity-devel] a small patch to add a little feature > On 4/10/08, David Bailes <drb...@go...> wrote: > This is better: > > Shift + home selects a time range from time zero to the cursor. > Shift + end selects a time range from the cursor to the end of all the tracks. > > In contrast, from the edit menu: > Select start to cursor selects a time range from the start of the data > in the selected tracks to the cursor. > Select cursor to end selects a time range from the cursor to the end > of the data in the selected tracks. Hi David Perhaps this boils down to whether "start to cursor" or "audio start to cursor" is most useful, and if we want new menu item(s) or hotkey(s). Can I just throw questions back into the ring? I think you are suggesting SHIFT + HOME and SHIFT + END stay functionally as they are now, which may be as well as they seem hardcoded somewhere (?). Then you want the select "cursor to end" command in the Edit menu to do (in practice) as now, but "start to cursor" becomes "audio start to cursor" (so that if none of the audio in the selected tracks is at time zero, the selected area starts not at zero, but at the start of the leftmost audio)? Or does having a time range to the end of all tracks when not all tracks are selected have a use that you don't get if that time range only goes as far right as the rightmost selected track? I don't see too many cases where if audio starts after zero, "start to cursor" gives us functionality that "audio start to cursor" does not. Generating is a case where the result is not the same, but in terms of duplicating, exporting or moving a clip, there is no difference. So should the "main" way of selecting start to cursor be a new "audio start to cursor"? If yes, then doesn't this need its own hotkey given its relative inaccessibility in a nested menu? Plus a hotkey for "cursor to audio end" if that has a distinct use? And then without adding another menu item for start to cursor, doesn't that remain rather undiscoverable? If we think we need new menu item(s), then how about adding the existing shortcuts alongside the "start to cursor" and "cursor to end" items as originally suggested, and just adding a new menu item (and possibly shortcut) for "audio start to cursor"? Gale |
From: David B. <drb...@go...> - 2008-04-14 12:00:24
|
On Fri, Apr 11, 2008 at 7:40 AM, Gale Andrews <ga...@au...> wrote: > > | From "David Bailes" <drb...@go...> > | Thu, 10 Apr 2008 20:59:40 +0100 > | Subject: [Audacity-devel] a small patch to add a little feature > > On 4/10/08, David Bailes <drb...@go...> wrote: > > This is better: > > > > Shift + home selects a time range from time zero to the cursor. > > Shift + end selects a time range from the cursor to the end of all the tracks. > > > > In contrast, from the edit menu: > > Select start to cursor selects a time range from the start of the data > > in the selected tracks to the cursor. > > Select cursor to end selects a time range from the cursor to the end > > of the data in the selected tracks. > > Hi David > > Perhaps this boils down to whether "start to cursor" or "audio start > to cursor" is most useful, and if we want new menu item(s) or > hotkey(s). Can I just throw questions back into the ring? > > I think you are suggesting SHIFT + HOME and SHIFT + END stay > functionally as they are now, which may be as well as they seem > hardcoded somewhere (?). > > Then you want the select "cursor to end" command in the Edit menu to > do (in practice) as now, but "start to cursor" becomes "audio start to > cursor" (so that if none of the audio in the selected tracks is at time > zero, the selected area starts not at zero, but at the start of the leftmost > audio)? Or does having a time range to the end of all tracks when not > all tracks are selected have a use that you don't get if that time range > only goes as far right as the rightmost selected track? > > I don't see too many cases where if audio starts after zero, "start to > cursor" gives us functionality that "audio start to cursor" does not. > Generating is a case where the result is not the same, but in terms > of duplicating, exporting or moving a clip, there is no difference. > So should the "main" way of selecting start to cursor be a new > "audio start to cursor"? > > If yes, then doesn't this need its own hotkey given its relative > inaccessibility in a nested menu? Plus a hotkey for "cursor to > audio end" if that has a distinct use? And then without adding > another menu item for start to cursor, doesn't that remain > rather undiscoverable? > > If we think we need new menu item(s), then how about adding > the existing shortcuts alongside the "start to cursor" and "cursor > to end" items as originally suggested, and just adding a new menu > item (and possibly shortcut) for "audio start to cursor"? Currently, Home moves the cursor to time zero, and End moves the cursor to the end of the data in all the tracks. A standard construct for selection keystrokes in SHIFT + navigation key, so the effects of SHIFT + HOME and SHIFT + END can't be changed unless HOME and END are also changed. I don't know how frequently the select "start to cursor" and "cursor to end" commands are used, as to whether they deserve shortcuts. However, if they did, then the move cursor to track start and end commands on the same menu should be allocated shortcuts,, and then the selection shortcuts should be constructed by adding shift. ( Move cursor to track start and end move to the start and end of the data in the selected tracks.) David. |
From: Gale A. <ga...@au...> - 2008-04-14 23:25:33
|
| From "David Bailes" <drb...@go...> | Mon, 14 Apr 2008 13:00:26 +0100 | Subject: [Audacity-devel] a small patch to add a little feature > On Fri, Apr 11, 2008 at 7:40 AM, Gale Andrews <ga...@au...> wrote: > > > > | From "David Bailes" <drb...@go...> > > | Thu, 10 Apr 2008 20:59:40 +0100 > > | Subject: [Audacity-devel] a small patch to add a little feature > > > On 4/10/08, David Bailes <drb...@go...> wrote: > > > This is better: > > > > > > Shift + home selects a time range from time zero to the cursor. > > > Shift + end selects a time range from the cursor to the end of all > > > the tracks. > > > > > > In contrast, from the edit menu: > > > Select start to cursor selects a time range from the start of the data > > > in the selected tracks to the cursor. > > > Select cursor to end selects a time range from the cursor to the end > > > of the data in the selected tracks. Hi David Well, I didn't realise given what Richard said in response to me, but in fact isn't what you describe above what happens now? So we don't want to put Shift + Home against the menu item "Select Start to Cursor" because "Select Start to Cursor" actually does "Select Track Start to Cursor".... > A standard construct for selection keystrokes (is) > SHIFT + navigation key ...in other words it's the selection construct for "Move Cursor to Track Start". This explains why Shift + Home still appeared to work when the binding for the (incorrectly named) "Select Start to Cursor" was changed. > I don't know how frequently the select "start to cursor" and "cursor > to end" commands are used, as to whether they deserve shortcuts. > However, if they did, then the move cursor to track start and end > commands on the same menu should be allocated shortcuts, and then > the selection shortcuts should be constructed by adding shift. Edit > "Select start to cursor" (meaning "select track start to cursor" and .. "select cursor to end" (meaning "select cursor to track end") are little used I suspect because: * they "appear" to have no shortcut according to the menu * (correct me if I'm wrong), when all tracks start at zero they are the same as Shift + Home and Shift + End Shift + Home and Shift + End are more generally useful IMO. They *are* already in the key bindings: command name="SelStart" label="Selection to Start" key="Shift+Home" command name="SelEnd" label="Selection to End" key="Shift+End" but they have no menu item at all so they are not really very discoverable. So do you have an idea for a good shortcut for Edit > Move Cursor > to Track Start and .. to Track End, for which a Shift-modified version is free for Edit > Select > Track Start to Cursor and .. Cursor to Track End? The bindings are already there: command name="CursTrackStart" label="to Track Start" key="" command name="CursTrackEnd" label="to Track End" key="" command name="SelStartCursor" label="Start to Cursor" key="" command name="SelCursorEnd" label="Cursor to End" key="" so the work is trivial (just rename SelStartCursor and "SelCursorEnd" and add the shortcut text to the menu). If we want actual menu items (I'd say yes): "Edit > Select > Start (meaning zero) to Cursor (Shift + Home)" "Edit > Select > Cursor to End (Shift + End)" then the bindings are there, but just needs new menu items. These two shortcuts probably need advertising a bit more in the Manual/Wiki, irrespective. Thanks Gale |
From: David B. <drb...@go...> - 2008-04-17 18:05:43
|
Hi Gale On 4/15/08, Gale Andrews <ga...@au...> wrote: > > | From "David Bailes" <drb...@go...> > | Mon, 14 Apr 2008 13:00:26 +0100 > | Subject: [Audacity-devel] a small patch to add a little feature > > On Fri, Apr 11, 2008 at 7:40 AM, Gale Andrews <ga...@au...> > wrote: > > > > > > | From "David Bailes" <drb...@go...> > > > | Thu, 10 Apr 2008 20:59:40 +0100 > > > | Subject: [Audacity-devel] a small patch to add a little feature > > > > On 4/10/08, David Bailes <drb...@go...> wrote: > > > > This is better: > > > > > > > > Shift + home selects a time range from time zero to the cursor. > > > > Shift + end selects a time range from the cursor to the end of all > > > > the tracks. > > > > > > > > In contrast, from the edit menu: > > > > Select start to cursor selects a time range from the start of the data > > > > in the selected tracks to the cursor. > > > > Select cursor to end selects a time range from the cursor to the end > > > > of the data in the selected tracks. > > Hi David > > Well, I didn't realise given what Richard said in response to me, > but in fact isn't what you describe above what happens now? So we > don't want to put Shift + Home against the menu item "Select Start to > Cursor" because "Select Start to Cursor" actually does "Select Track > Start to Cursor".... > > > A standard construct for selection keystrokes (is) > > SHIFT + navigation key > > ...in other words it's the selection construct for "Move Cursor > to Track Start". This explains why Shift + Home still appeared > to work when the binding for the (incorrectly named) "Select > Start to Cursor" was changed. > > > I don't know how frequently the select "start to cursor" and "cursor > > to end" commands are used, as to whether they deserve shortcuts. > > However, if they did, then the move cursor to track start and end > > commands on the same menu should be allocated shortcuts, and then > > the selection shortcuts should be constructed by adding shift. > > Edit > "Select start to cursor" (meaning "select track start to cursor" > and .. "select cursor to end" (meaning "select cursor to track end") are > little used I suspect because: > > * they "appear" to have no shortcut according to the > menu I think it's more likely that either there not used very much, or it's unclear from the menu text what they do. > * (correct me if I'm wrong), when all tracks start at zero > they are the same as Shift + Home and Shift + End If at least one of the tracks is selected then "select start to cursor" is the same as shift + home. If the tracks are of different lengths, then "select cursor to end" is only the same as shift + end if all the tracks are selected. > > Shift + Home and Shift + End are more generally useful IMO. They > *are* already in the key bindings: > > command name="SelStart" label="Selection to Start" key="Shift+Home" > command name="SelEnd" label="Selection to End" key="Shift+End" > > but they have no menu item at all so they are not really very > discoverable. but they do the same sort of thing in alot of programs. > > So do you have an idea for a good shortcut for Edit > Move Cursor > > to Track Start and .. to Track End, for which a Shift-modified version > is free for Edit > Select > Track Start to Cursor and .. Cursor to Track > End? The bindings are already there: > > command name="CursTrackStart" label="to Track Start" key="" > command name="CursTrackEnd" label="to Track End" key="" > command name="SelStartCursor" label="Start to Cursor" key="" > command name="SelCursorEnd" label="Cursor to End" key="" > > so the work is trivial (just rename SelStartCursor and > "SelCursorEnd" and add the shortcut text to the menu). > > If we want actual menu items (I'd say yes): > > "Edit > Select > Start (meaning zero) to Cursor (Shift + Home)" > "Edit > Select > Cursor to End (Shift + End)" > > then the bindings are there, but just needs new menu items. > These two shortcuts probably need advertising a bit more in the > Manual/Wiki, irrespective. Unless there's a great demand for a shortcuts, then allocating them, given the crowded nature of existing shortcuts, doesn't seem like a good idea. However, some of the items on the Select and Move cursor sub-menus don't have access keys, and I guess that should be fixed at some stage. There does seem to be some inconsistent use of terms like start, track start etc. Consistency in terms both in menus and documentation would help. My understanding is that until post 1.4, stuff like this isn't a priority, and minor changes will slow down getting 1.4 out. David. |
From: Gale A. <ga...@au...> - 2008-04-22 07:59:36
|
| From "David Bailes" <drb...@go...> | Thu, 17 Apr 2008 19:05:30 +0100 | Subject: [Audacity-devel] a small patch to add a little feature > On 4/15/08, Gale Andrews <ga...@au...> wrote: > > * (correct me if I'm wrong), when all tracks start at zero > > they are the same as Shift + Home and Shift + End > > If at least one of the tracks is selected then "select start to > cursor" is the same as shift + home. But not unless at least the selected track starts at zero? > > Shift + Home and Shift + End are more generally useful IMO. They > > *are* already in the key bindings: > > > > command name="SelStart" label="Selection to Start" key="Shift+Home" > > command name="SelEnd" label="Selection to End" key="Shift+End" > > > > but they have no menu item at all so they are not really very > > discoverable. > > but they do the same sort of thing in alot of programs Yes, but even some advanced users don't realise that (maybe because they think same rules don't apply in audio editors as document editors)? > > So do you have an idea for a good shortcut for Edit > Move Cursor > > > to Track Start and .. to Track End, for which a Shift-modified version > > is free for Edit > Select > Track Start to Cursor and .. Cursor to Track > > End? The bindings are already there: > > > > command name="CursTrackStart" label="to Track Start" key="" > > command name="CursTrackEnd" label="to Track End" key="" > > command name="SelStartCursor" label="Start to Cursor" key="" > > command name="SelCursorEnd" label="Cursor to End" key="" > > > > so the work is trivial (just rename SelStartCursor and > > "SelCursorEnd" and add the shortcut text to the menu). > > > > If we want actual menu items (I'd say yes): > > > > "Edit > Select > Start (meaning zero) to Cursor (Shift + Home)" > > "Edit > Select > Cursor to End (Shift + End)" > > > > then the bindings are there, but just needs new menu items. > > These two shortcuts probably need advertising a bit more in the > > Manual/Wiki, irrespective. > > Unless there's a great demand for a shortcuts, then allocating them, > given the crowded nature of existing shortcuts, doesn't seem like a > good idea. It seems not as crowded as I thought - even of the purely alphabetic characters, 15 are available to choose from for "Cursor to Track Start" and "Cursor to Track End", with a shift-modified equivalent for the selection variant. How about "\" for "Move Cursor... to Track Start" and "/" for "Move Cursor... to Track End"? That works fine for me in my copy, with the menu items under "Select..." modified to read: "Track Start to Cursor Shift+\" "Cursor to Track End Shift + /" Or "X" and "Y"? I'm finding it useful, normally I would use the mouse without thinking. > However, some of the items on the Select and Move cursor sub-menus > don't have access keys, and I guess that should be fixed at some > stage. > > There does seem to be some inconsistent use of terms like start, track > start etc. Consistency in terms both in menus and documentation would > help. > > My understanding is that until post 1.4, stuff like this isn't a > priority, and minor changes will slow down getting 1.4 out. Well I can fix the submenu access keys since there seems no block on using a letter already used in the main menu. Suggestions? Is there any other inconsistency apart from clarifying where we mean track start/end and project start/end? Not quite sure whether we need menu items for "Select... Start to Cursor" and "Select...Cursor to End. It would make eight items in that submenu (we have nine in "Labeled Regions" submenu), and obviously I'd need to do some research before I started adding menus myself. Any views? Leave as is? Gale |
From: David B. <drb...@go...> - 2008-04-23 09:12:14
|
Hi Gale, On Tue, Apr 22, 2008 at 8:59 AM, Gale Andrews <ga...@au...> wrote: > > | From "David Bailes" <drb...@go...> > | Thu, 17 Apr 2008 19:05:30 +0100 > | Subject: [Audacity-devel] a small patch to add a little feature > > On 4/15/08, Gale Andrews <ga...@au...> wrote: > > > * (correct me if I'm wrong), when all tracks start at zero > > > they are the same as Shift + Home and Shift + End > > > > If at least one of the tracks is selected then "select start to > > cursor" is the same as shift + home. > > But not unless at least the selected track starts at zero? I was continuing to make the assumption that you'd stated that all tracks start at zero > It seems not as crowded as I thought - even of the purely alphabetic > characters, 15 are available to choose from for "Cursor to Track Start" > and "Cursor to Track End", with a shift-modified equivalent for the > selection variant. How about "\" for "Move Cursor... to Track Start" and > "/" for "Move Cursor... to Track End"? That works fine for me in my copy, > with the menu items under "Select..." modified to read: > > "Track Start to Cursor Shift+\" > "Cursor to Track End Shift + /" > > Or "X" and "Y"? I'm finding it useful, normally I would use the mouse > without thinking. Microsoft advise against using \ for shortcut (but don't give a reason). If using letters, then j and k would be more keyboard friendly than x and y. ctrl + home and ctrl + end might have been a possibility but using them would go against the convention that ctrl + keystroke is a larger scale version of just keystroke, so I don't think they would be suitable. > > However, some of the items on the Select and Move cursor sub-menus > > don't have access keys, and I guess that should be fixed at some > > stage. > > > > There does seem to be some inconsistent use of terms like start, track > > start etc. Consistency in terms both in menus and documentation would > > help. > > > > My understanding is that until post 1.4, stuff like this isn't a > > priority, and minor changes will slow down getting 1.4 out. > > Well I can fix the submenu access keys since there seems no > block on using a letter already used in the main menu. > Suggestions? On the select sub menu, you could use the access keys l, r, s and e for the last four items. On the move cursor sub menu, you could use the access keys t, d, s and e. I think its right to give the track start and end items the more obvious access keys, since there shortcuts to move to start and end of selection (left and right arrow). > Is there any other inconsistency apart from > clarifying where we mean track start/end and project start/end? Following are two alternatives for making menus + tool tips more consistent. The first emphasizes that tracks and audio clips are different objects: tracks contain audio clips and tracks start at zero. control toolbar tool tip (home) "skip to start" : skip to track start control toolbar tool tip (end) "skip to end" : skip to end of all audio edit>select>start to cursor : audio start to cursor edit>select>cursor to end : cursor to audio end edit>move cursor>to track start : to audio start edit>move cursor>to track end : to audio end tracks>align tracks>align with zero : align with track start Second alternative: control toolbar tool tip (home) "skip to start" : skip to zero control toolbar tool tip (end) "skip to end" : skip to end of all tracks edit>select>start to cursor : track start to cursor edit>select>cursor to end : cursor to track end edit>move cursor>to track start : to track start edit>move cursor>to track end : to track end tracks>align tracks>align with zero : align with zero I'm not sure if it's enough that on the edit menu it's implicit that all the commands operate only on selected tracks. Perhaps it just needs to be stressed in the documentation rather than being included explicitly in the menu text, which would make some of the items long (but perhaps clearer). > > Not quite sure whether we need menu items for "Select... Start > to Cursor" and "Select...Cursor to End. It would make eight items > in that submenu (we have nine in "Labeled Regions" submenu), > and obviously I'd need to do some research before I started adding > menus myself. Any views? Leave as is? Not sure! David. |
From: Gale A. <ga...@au...> - 2008-04-26 04:43:07
|
| From "David Bailes" <drb...@go...> | Wed, 23 Apr 2008 10:12:13 +0100 | Subject: [Audacity-devel] a small patch to add a little feature > On Tue, Apr 22, 2008 at 8:59 AM, Gale Andrews <ga...@au...> wrote: > > | From "David Bailes" <drb...@go...> > > | Thu, 17 Apr 2008 19:05:30 +0100 > > | Subject: [Audacity-devel] a small patch to add a little feature > > > On 4/15/08, Gale Andrews <ga...@au...> wrote: > > > > * (correct me if I'm wrong), when all tracks start at zero > > > > they are the same as Shift + Home and Shift + End > > > > > > If at least one of the tracks is selected then "select start to > > > cursor" is the same as shift + home. > > > > But not unless at least the selected track starts at zero? > > I was continuing to make the assumption that you'd stated that all > tracks start at zero Of course, sorry! Must have had the assumption off the scroll. > > It seems not as crowded as I thought - even of the purely alphabetic > > characters, 15 are available to choose from for "Cursor to Track Start" > > and "Cursor to Track End", with a shift-modified equivalent for the > > selection variant. How about "\" for "Move Cursor... to Track Start" and > > "/" for "Move Cursor... to Track End"? That works fine for me in my copy, > > with the menu items under "Select..." modified to read: > > > > "Track Start to Cursor Shift+\" > > "Cursor to Track End Shift + /" > > > > Or "X" and "Y"? I'm finding it useful, normally I would use the mouse > > without thinking. > > Microsoft advise against using \ for shortcut (but don't give a > reason). It may be something to do with it being an escape character in code (?), meaning I had to escape it with itself to make it work. Anyway, though it works beautifully with my UK layout keyboard (either shift key next to the shortcut key), it looks as if it may be a liability with other layouts: http://en.wikipedia.org/wiki/Keyboard_layout as some layouts don't let you produce "/" or "\" without using a modifier. > If using letters, then j and k would be more keyboard > friendly than x and y. ctrl + home and ctrl + end might have been a > possibility but using them would go against the convention that ctrl + > keystroke is a larger scale version of just keystroke, so I don't > think they would be suitable. I think including home and end in all eight shortcuts might be more intuitive, but like you say maybe not when HOME means to project start. If we were starting from scratch, would: Select ... Track Start to Cursor SHIFT + HOME ... Cursor to Track End SHIFT + END ... Start to Cursor CTRL + SHIFT + HOME ... Cursor to End CTRL + SHIFT + END Move Cursor... to Track Start HOME ... to Track End END ... to Start CTRL + HOME ... to End CTRL + END have been more logical? Is the double modifier thought too ungainly for a common action? But as it is now, if we need two side by side alphabetical keys, then J and K instead of \ and / do indeed look the best choice to me also. > On the select sub menu, you could use the access keys l, r, s and e > for the last four items. > On the move cursor sub menu, you could use the access keys t, d, s and > e. I think its right to give the track start and end items the more > obvious access keys, since there shortcuts to move to start and end of > selection (left and right arrow). Fine by me. Shall I deal with these as well that are missing access keys:? * View > Show Clipping (s) * Generate > all five items (first letter of item) (which then implies adding keys to Effects, which I'm prepared to if it's a significant benefit?) * Analye > two items (first letter) > > Is there any other inconsistency apart from > > clarifying where we mean track start/end and project start/end? > > Following are two alternatives for making menus + tool tips more > consistent. The first emphasizes that tracks and audio clips are > different objects: tracks contain audio clips and tracks start at > zero. > > control toolbar tool tip (home) "skip to start" : skip to track start > control toolbar tool tip (end) "skip to end" : skip to end of all audio > edit>select>start to cursor : audio start to cursor > edit>select>cursor to end : cursor to audio end > edit>move cursor>to track start : to audio start > edit>move cursor>to track end : to audio end > tracks>align tracks>align with zero : align with track start > > Second alternative: > > control toolbar tool tip (home) "skip to start" : skip to zero > control toolbar tool tip (end) "skip to end" : skip to end of all tracks > edit>select>start to cursor : track start to cursor > edit>select>cursor to end : cursor to track end > edit>move cursor>to track start : to track start > edit>move cursor>to track end : to track end > tracks>align tracks>align with zero : align with zero&& I prefer to the second alternative which is closer to what we have now, because we have always tended to talk in documentation about project start to mean zero, and track start to mean start of audio. We'd also have to change Tracks > Align Tracks > Align Tracks Together. In the second alternative, "skip to end of all tracks" is I think a bit long. I don't sense much user confusion with "start" and "end" implying "of project", but I have seen confusion over "zero" in the menus. I think not having consistency here between the menus and the |<< button tooltip does make some sense, as the button is basic and the menus involving "zero" advanced. I would not recommend renaming the button tooltip to "skip to zero". So my vote using the second alternative is: a) if we want consistency: control toolbar tool tip (home) "skip to start": skip to project start control toolbar tool tip (end) "skip to end" : skip to project end edit>select>start to cursor : track start to cursor edit>select>cursor to end : cursor to track end edit>move cursor>to track start : to track start edit>move cursor>to track end : to track end tracks>align tracks>align with zero : align with project start tracks>align and move cursor>align with zero: align with project start b) if we can be more flexible: control toolbar tool tip (home) "skip to start": skip to start control toolbar tool tip (end) "skip to end" : skip to end edit>select>start to cursor : track start to cursor edit>select>cursor to end : cursor to track end edit>move cursor>to track start : to track start edit>move cursor>to track end : to track end tracks>align tracks>align with zero : align with time zero tracks>align and move cursor>align with zero: align with time zero > I'm not sure if it's enough that on the edit menu it's implicit that > all the commands operate only on selected tracks. Perhaps it just > needs to be stressed in the documentation rather than being included > explicitly in the menu text, which would make some of the items long > (but perhaps clearer). Well I don't think we could add the word "selection" against a large number of menu items. We could have a submenu "Selection..." but is a submenu a good idea for common actions? Perhaps this might even have helped the newbie confusion (in this menu) over having to select audio first. But as it is now, with select-all- on-none the default, probably clarifying documentation is better, which I think we largely have done now. > > Not quite sure whether we need menu items for "Select... Start > > to Cursor" and "Select...Cursor to End. It would make eight items > > in that submenu (we have nine in "Labeled Regions" submenu), > > and obviously I'd need to do some research before I started adding > > menus myself. Any views? Leave as is? > > Not sure! Leaving aside changing menus at the moment, I would like to do what simple rewordings/adding access keys we can agree on in the next few days as we are having a string freeze soon. I imagine J and K (given the text alongside), and the Edit, View and Analyze Menu access keys are uncontroversial. Deciding on the Zero/Start issue would be good too. Gale |
From: David B. <drb...@go...> - 2008-04-26 11:54:25
|
Hi Gale, On 4/26/08, Gale Andrews <ga...@au...> wrote: > If we were starting from scratch, would: > > Select ... Track Start to Cursor SHIFT + HOME > ... Cursor to Track End SHIFT + END > ... Start to Cursor CTRL + SHIFT + HOME > ... Cursor to End CTRL + SHIFT + END > > Move Cursor... to Track Start HOME > ... to Track End END > ... to Start CTRL + HOME > ... to End CTRL + END > > have been more logical? Is the double modifier thought too ungainly > for a common action? Yes. Yes. > Fine by me. Shall I deal with these as well that are missing access > keys:? > > * View > Show Clipping (s) > * Generate > all five items (first letter of item) (which then implies > adding keys to Effects, which I'm prepared to if it's a significant > benefit?) > * Analye > two items (first letter) It ok to add the access key on the View menu. On the Effects menu, people add there own plug-ins which don't have access keys. David Sky found that if items with and without access keys are mixed on the same menu, then you can't reach the items without access keys by using their first letter (in some progs this is ok, but obviously not in audactiy) He therefore asked for the access keys for the initial items to be removed and they were. I think the effects menu is very similar to favorites or bookmarks menus in browsers, where navigation is by first letter. I assume that the Generate and Analyse menus similarly have personal items added, and so thier items shouldn't have acess keys. In passing why is Regular interval labes in the Analyse menu rather than the Generate menu? > > > Is there any other inconsistency apart from > > > clarifying where we mean track start/end and project start/end? > > > > Following are two alternatives for making menus + tool tips more > > consistent. The first emphasizes that tracks and audio clips are > > different objects: tracks contain audio clips and tracks start at > > zero. > > > > control toolbar tool tip (home) "skip to start" : skip to track start > > control toolbar tool tip (end) "skip to end" : skip to end of all audio > > edit>select>start to cursor : audio start to cursor > > edit>select>cursor to end : cursor to audio end > > edit>move cursor>to track start : to audio start > > edit>move cursor>to track end : to audio end > > tracks>align tracks>align with zero : align with track start > > > > Second alternative: > > > > control toolbar tool tip (home) "skip to start" : skip to zero > > control toolbar tool tip (end) "skip to end" : skip to end of all tracks > > edit>select>start to cursor : track start to cursor > > edit>select>cursor to end : cursor to track end > > edit>move cursor>to track start : to track start > > edit>move cursor>to track end : to track end > > tracks>align tracks>align with zero : align with zero&& > > I prefer to the second alternative which is closer to what we have > now, because we have always tended to talk in documentation about > project start to mean zero, and track start to mean start of audio. > We'd also have to change Tracks > Align Tracks > Align Tracks Together. > > In the second alternative, "skip to end of all tracks" is I think a bit > long. I don't sense much user confusion with "start" and "end" implying > "of project", Here's a little: http://audacityteam.org/manual/index.php?title=Control_Toolbar which incorrectly descibes skip to start. >but I have seen confusion over "zero" in the menus. > I think not having consistency here between the menus and the > |<< button tooltip does make some sense, as the button is basic > and the menus involving "zero" advanced. I would not recommend > renaming the button tooltip to "skip to zero". > > So my vote using the second alternative is: > > a) if we want consistency: > control toolbar tool tip (home) "skip to start": skip to project start > control toolbar tool tip (end) "skip to end" : skip to project end I don't find it intuitive that the start of a project is time zero (not the start of the audio) and that it's end is the end of the audio. > edit>select>start to cursor : track start to cursor > edit>select>cursor to end : cursor to track end > edit>move cursor>to track start : to track start > edit>move cursor>to track end : to track end > tracks>align tracks>align with zero : align with project start > tracks>align and move cursor>align with zero: align with project start > > b) if we can be more flexible: > control toolbar tool tip (home) "skip to start": skip to start > control toolbar tool tip (end) "skip to end" : skip to end > edit>select>start to cursor : track start to cursor > edit>select>cursor to end : cursor to track end > edit>move cursor>to track start : to track start > edit>move cursor>to track end : to track end > tracks>align tracks>align with zero : align with time zero > tracks>align and move cursor>align with zero: align with time zero As you might have guessed I would prefer some variation of the first option. - I think that audio start is just as clear if not clearer than track start - tracks are objects in the interface which appear to start at time zero - the tool-tips skip to start and skip to end are confusing because they don't refer to the same object (see comments about start and end of project above) Skip to track start and skip to audio end would make things clearer. > Deciding on the Zero/Start issue would > be good too. I think we need the views of the developers as whether making the tool-tip and menu item text more consistent is worth doing now, and if so how. It doesn't seem to have aroused much interest so far! David. |
From: Gale A. <ga...@au...> - 2008-04-26 18:53:12
|
| From "David Bailes" <drb...@go...> | Sat, 26 Apr 2008 12:54:28 +0100 | Subject: [Audacity-devel] a small patch to add a little feature > On 4/26/08, Gale Andrews <ga...@au...> wrote: > > > If we were starting from scratch, would: > > > > Select ... Track Start to Cursor SHIFT + HOME > > ... Cursor to Track End SHIFT + END > > ... Start to Cursor CTRL + SHIFT + HOME > > ... Cursor to End CTRL + SHIFT + END > > > > Move Cursor... to Track Start HOME > > ... to Track End END > > ... to Start CTRL + HOME > > ... to End CTRL + END > > > > have been more logical? Is the double modifier thought too ungainly > > for a common action? > > Yes. Yes. Seems you can't win then.. what's logical isn't always best. > > Fine by me. Shall I deal with these as well that are missing access > > keys:? > > > > * View > Show Clipping (s) > > * Generate > all five items (first letter of item) (which then implies > > adding keys to Effects, which I'm prepared to if it's a significant > > benefit?) > > * Analye > two items (first letter) > > It ok to add the access key on the View menu. On the Effects menu, > people add there own plug-ins which don't have access keys. David Sky > found that if items with and without access keys are mixed on the same > menu, then you can't reach the items without access keys by using > their first letter (in some progs this is ok, but obviously not in > audactiy) He therefore asked for the access keys for the initial items > to be removed and they were. I think the effects menu is very similar > to favorites or bookmarks menus in browsers, where navigation is by > first letter. I assume that the Generate and Analyse menus similarly > have personal items added, and so thier items shouldn't have acess > keys. True, I just tried giving Amplify an "a" access key and of course it launches the dialogue. So we just accept that some menus use access keys and some don't, because we can't control the latter. Should have realised that when I wrote really. > In passing why is Regular interval labes in the Analyse menu rather > than the Generate menu? I think this is correct. Plug-ins in the Generate menu generate sounds, Regular Interval Labels doesn't generate sound. > > > > Is there any other inconsistency apart from > > > > clarifying where we mean track start/end and project start/end? > > > > > > Following are two alternatives for making menus + tool tips more > > > consistent. The first emphasizes that tracks and audio clips are > > > different objects: tracks contain audio clips and tracks start at > > > zero. > > > > > > control toolbar tool tip (home) "skip to start" : skip to track start > > > control toolbar tool tip (end) "skip to end" : skip to end of all audio > > > edit>select>start to cursor : audio start to cursor > > > edit>select>cursor to end : cursor to audio end > > > edit>move cursor>to track start : to audio start > > > edit>move cursor>to track end : to audio end > > > tracks>align tracks>align with zero : align with track start > > > > > > Second alternative: > > > > > > control toolbar tool tip (home) "skip to start" : skip to zero > > > control toolbar tool tip (end) "skip to end" : skip to end of all tracks > > > edit>select>start to cursor : track start to cursor > > > edit>select>cursor to end : cursor to track end > > > edit>move cursor>to track start : to track start > > > edit>move cursor>to track end : to track end > > > tracks>align tracks>align with zero : align with zero&& > > > > I prefer to the second alternative which is closer to what we have > > now, because we have always tended to talk in documentation about > > project start to mean zero, and track start to mean start of audio. > > We'd also have to change Tracks > Align Tracks > Align Tracks Together. > > > > In the second alternative, "skip to end of all tracks" is I think a bit > > long. I don't sense much user confusion with "start" and "end" implying > > "of project", > > Here's a little: > http://audacityteam.org/manual/index.php?title=Control_Toolbar > > which incorrectly descibes skip to start. Thanks. I changed it to read that the buttons skip to start and end of the project, not of the audio. > > but I have seen confusion over "zero" in the menus. > > I think not having consistency here between the menus and the > > |<< button tooltip does make some sense, as the button is basic > > and the menus involving "zero" advanced. I would not recommend > > renaming the button tooltip to "skip to zero". > > > > So my vote using the second alternative is: > > > > a) if we want consistency: > > control toolbar tool tip (home) "skip to start": skip to project start > > control toolbar tool tip (end) "skip to end" : skip to project end > > I don't find it intuitive that the start of a project is time zero > (not the start of the audio) and that it's end is the end of the > audio. The Skip to Start button goes to time zero. I don't think we should change its tooltip to say "Skip to Zero" or change the button behaviour. Zero in my view is the start of the project because you could generate new audio at that zero point. > > edit>select>start to cursor : track start to cursor > > edit>select>cursor to end : cursor to track end > > edit>move cursor>to track start : to track start > > edit>move cursor>to track end : to track end > > tracks>align tracks>align with zero : align with project start > > tracks>align and move cursor>align with zero: align with project start > > > > b) if we can be more flexible: > > control toolbar tool tip (home) "skip to start": skip to start > > control toolbar tool tip (end) "skip to end" : skip to end > > edit>select>start to cursor : track start to cursor > > edit>select>cursor to end : cursor to track end > > edit>move cursor>to track start : to track start > > edit>move cursor>to track end : to track end > > tracks>align tracks>align with zero : align with time zero > > tracks>align and move cursor>align with zero: align with time zero > > As you might have guessed I would prefer some variation of the first option. > - I think that audio start is just as clear if not clearer than track start > - tracks are objects in the interface which appear to start at time zero > - the tool-tips skip to start and skip to end are confusing because > they don't refer to the same object (see comments about start and end > of project above) Skip to track start and skip to audio end would make > things clearer. "Skip to track start" IMHO would confuse if the audio (or track as I would prefer to call it) does not not start at zero. I still feel (despite the Manual hiccup above!) that because we have always tended to talk in documentation about project start to mean zero, and track start to mean start of audio, we shouldn't change to mean track start equals "fixed at time zero". For example we talk about time shifting a track, which means that instead of starting at zero it starts elsewhere. If there was very significant user confusion about this, I'd take a different view, but I'm not aware of such. > > > > Deciding on the Zero/Start issue would > > be good too. > > I think we need the views of the developers as whether making the > tool-tip and menu item text more consistent is worth doing now, and if > so how. It doesn't seem to have aroused much interest so far! Indeed :=). But if there's no reaction or clear answer I think I should go ahead and add the J and K and the Edit/View access keys, and fix the Edit > Select... submenu so that it's clear "Start" and "End" as they are now really mean "Track" start and end. Thanks Gale |
From: Gale A. <ga...@au...> - 2008-04-28 07:09:29
|
| From Gale Andrews <ga...@au...> | Sat, 26 Apr 2008 19:53:04 +0100 | Subject: [Audacity-devel] a small patch to add a little feature Richard wrote:"Get any remaining string changes made, push the pot file to the website, then some release candidate builds. I've pushed the current pot file now, will do so again once we have a release candidate available". So I've committed the following to Menus.cpp: * fixed the Edit > Select... submenu to clarify that start and end of track (not project) is selected. * added the new Shift + J/ Shift + K shortcuts for these, and J and K for Move Cursor... to track start/end. * Filled in all missing access keys for the Edit, View and Tracks menus/submenus I came across an unexpected problem in the Edit menu - the Redo and Silence access keys weren't working because their keys are used elsewhere in the menu. Rather than wait for more discussions (since another string change is involved) I've included in the commit provisional fixes to get these keys working, and to provide access keys for the useful Selection Save/Restore functions which are a long way down the menu. I can revert anything if the changes are felt worse than not having working keys, but at least it gives us a possible solution to consider: * Labeled Regions: access key from "g" to "b" * Select...: access key from "s" to "." * "Selection Save" and "Selection Restore" renamed to "Region Save" and "Region Restore" (access keys "g" and "n" respectively). This has an additional benefit (in my view) of helping user confusion that this function restores the selected audio content of the saved selection * Play Region: access key from "r" to "y" If CleanSpeech mode is enabled, the access key for Silence again does not work because "&Stereo to Mono" is imported into the Edit menu. This could be fixed by renaming to "Ma&ke Mono", presumably in both menus, but I did not do that. (Was it called that in the past)? If David needs a Windows build to check: http://www.gaclrecords.org.uk/audacity-latest-cvs.zip Hope this of some use. Gale |
From: Vaughan J. <va...@au...> - 2008-04-28 18:43:40
|
Thanks, Gale. Looks like good decisions. CleanSpeech should definitely have lower precedence than key shortcuts for the more-used standard commands. - Vaughan Gale Andrews wrote: > | From Gale Andrews <ga...@au...> > | Sat, 26 Apr 2008 19:53:04 +0100 > | Subject: [Audacity-devel] a small patch to add a little feature > > Richard wrote:"Get any remaining string changes made, push the pot file > to the website, then some release candidate builds. I've pushed the > current pot file now, will do so again once we have a release candidate > available". > > So I've committed the following to Menus.cpp: > > * fixed the Edit > Select... submenu to clarify that start and end of > track (not project) is selected. > * added the new Shift + J/ Shift + K shortcuts for these, and J and K > for Move Cursor... to track start/end. > * Filled in all missing access keys for the Edit, View and Tracks > menus/submenus > > I came across an unexpected problem in the Edit menu - the Redo > and Silence access keys weren't working because their keys are used > elsewhere in the menu. Rather than wait for more discussions (since > another string change is involved) I've included in the commit > provisional fixes to get these keys working, and to provide access keys > for the useful Selection Save/Restore functions which are a long way > down the menu. I can revert anything if the changes are felt worse than > not having working keys, but at least it gives us a possible solution to > consider: > > * Labeled Regions: access key from "g" to "b" > * Select...: access key from "s" to "." > * "Selection Save" and "Selection Restore" renamed to > "Region Save" and "Region Restore" (access keys > "g" and "n" respectively). This has an additional benefit > (in my view) of helping user confusion that this function > restores the selected audio content of the saved selection > * Play Region: access key from "r" to "y" > > If CleanSpeech mode is enabled, the access key for Silence again > does not work because "&Stereo to Mono" is imported into > the Edit menu. This could be fixed by renaming to "Ma&ke Mono", > presumably in both menus, but I did not do that. (Was it called that > in the past)? > > If David needs a Windows build to check: > http://www.gaclrecords.org.uk/audacity-latest-cvs.zip > > Hope this of some use. > > > Gale > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > |