Re: [Audacity-devel] Development of an audio tool

[David M. <be...@ma...>]

Hi Folks

I'm the W3C, WCAG contact for this tool. 

I'm not sure this is possible in the Audacity environment, but if so it
would solve most of the issues discussed here. It appears that all Audacity
Plugins are currently "attached" to the program, they are Modal dialogue
boxes and they grab focus while open and do not allow anything else in the
program to get focus... I think this is pretty limiting and unique among
audio editors. 

If we could turn this into a non-modal dialogue box, (can do other things
while it is there) we could make the foreground and background selections
while the dialogue box is open. Wavelab and Cubase and most other audio
programs work this way. Thoughts?


David MacDonald

access empowers people...
        ...barriers disable them...
 
www.eramp.com
-----Original Message-----
From: Martyn Shaw [mailto:mar...@go...] 
Sent: Sunday, November 09, 2008 1:00 PM
To: aud...@li...
Cc: David MacDonald
Subject: Re: [Audacity-devel] Development of an audio tool



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
>