Re: [Audacity-devel] Development of an audio tool
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Martyn S. <mar...@go...> - 2008-11-09 17:56:50
|
Gale Andrews wrote: > | From Martyn Shaw <mar...@go...> > | Fri, 07 Nov 2008 01:16:14 +0000 > | Subject: [Audacity-devel] Development of an audio tool >>> | From Gale Andrews >>> I think my only real issue is the divorce of the Analyzer from the >>> visible selection region, making it unlike the other effects and tools. >> True, but you need to select 2 regions (foreground, background) for >> this, so which one is the selected region? > > If it was possible to do it, (assuming we are stuck with one visible > region at a time), the selected region is the one last captured with the > shortcuts (whose start time shows selected in the box in the tool), or > the one last selected in those boxes. If you haven't changed the selection since Ctrl+Alt+F/B then the selected region is the one last captured. >>> So there could be confusion as to what it does if you call it up without >>> selecting the foreground/background first with the shortcuts, which >>> you can do when the default preference "Select all audio... if none >>> selected" is on. It is especially confusing if you have used it before, >>> so that the Start/End boxes have values which bear no relation to any >>> visible selection region. >> Again true, but what else to do? I am storing start and stop times in >> prefs. I'd appreciate ideas. > > If we can find a way to work on selection regions, this problem disappears. > If not, well perhaps discard values when user clicks OK on the dialogue. Or > at least, discard them on exit, as they are with most effects. Possible (easier not to read them on load, perhaps). But what if a user re-loads the same file they were working on before? Why throw away possibly useful information? > ... Most people are going to figure they > need to/can also make a selection and then call the tool, aren't they? And > they'll call it broken when they make a selection and it has no result in the > boxes... Maybe. We could have a button in the dialog to set the start/end time from the current selection. But that would look even more confusing I think. > If the tool is called with a region selected it could as I suggested treat > that as foreground and calculate it as if you had done CTRL + ALT + F > and then called the tool. Some people are going to do that anyway. > So from that point, maybe let them use common sense (or the Wiki) > and enter the background times. People who selected the region and > called the tool are better off, as they have the foreground calculated. That would make it asymmetric; they would have to different things for background and foreground. I'm not sure about that, although it would be easy to implement, for sure. Any input from others? ... > A modeless dialogue might still be good if you do work out how to > type in the start/end boxes and have them draw the region. Does: > http://docs.wxwidgets.org/2.8.9/wx_wxdialog.html > > help? Or can anyone else or in the University Team help with this, > or with drawing selection regions? The original requirements document > did call for displaying the selection regions, so I thought that was the > intention. I'll continue to look into a modeless dialog, it was the original intention. >>> Another benefit of relating the dialogue to visible regions would be to >>> get over the current problem that the shortcuts method has no indication >>> if the region has been captured - it might not have been for rapid or >>> light-fingered typists/people with stiff keyboards. But if CTRL + ALT + F >>> brought up the (modeless) dialogue with the region showing in the >>> Foreground boxes, and let you use CTRL + ALT + B with the dialogue >>> still visible, then I think again we have something more intuitive. >> What do you think of the status bar additions I made? At least it >> gives a (brief) indication that something was selected. > > I don't see them in ANSI Release, only the usual status bar messages we > always had. I am updated. That's odd, they work in Release here. They are only there while you have Ctrl+Alt+F/B actually pressed though. Did you miss that? > What do they say? Something that said after > CTRL + ALT + F "Foreground captured: press CTRL + ALT + B to > capture background" might help. We already have "click and drag to > move xx selection boundary" after drag is released, so don't have much > space to add anything there unless yours disappears after a couple of > seconds. "Foreground audio selection saved (for Analyze->Contrast)" "Background audio selection saved (for Analyze->Contrast)" TTFN Martyn > I guess we also need to figure how to handle foreground and background > being in different tracks, which fools the analyser currently, and what to > do if more than one track is selected when the captures are made (maybe > someone will think it should work out the mixed result)? > > > Gale > > > >>>>> | From David MacDonald >>>>> | Mon, 6 Oct 2008 17:31:17 -0400 >>>>> | Subject: Development of an audio tool >>>>> >>>>>> I'm looking for some help to develop a simple tool that will help >>>>>> hard of hearing people. It is for a worldwide standard. It would >>>>>> measure the average RMS value for two sections of an audio file >>>>>> and subtract the second selection from the first to calculate the >>>>>> volume difference in dBs. I've attached a requirements document. >>>>>> >>>>>> There would be some payment involved in the development which is >>>>>> being done by Trace Research at the University of Wisconsin-Madison. >>>>>> >>>>>> Does anyone on your team interested, capable and have the time to >>>>>> do this in the next month or so to do this. >>>>>> >>>>> I am C'cing to our Team address so that all the Team can see this, >>>>> but we are all volunteers working on Audacity in our spare time, >>>>> and are trying to get a release of Audacity out this month. Would >>>>> this (also) be useful as a tool under the Analyze menu in Audacity, >>>>> so perhaps make it more likely we could work on it? It also gives >>>>> some possibility to actually correct the audio, for which another >>>>> tool than yours is needed anyway. >>>>> >>>>> >>>>> Gale >>>>> Audacity Team > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |