Focus Plus Context Audacity Demo (screencast)

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Focus Plus Context Audacity Demo (screencast)

Brett Park-2
I recently did a presentation on a new interface concept for editing audio. The concept involves something called Focus-Plus-Context interfaces. 
Anyways, you can check out the screencast at 
http://www.research.parknation.com/index.php 

The screencast goes through and explains Focus Plus Context in leman terms. The video is about 13 minutes. But, if you just want to skip ahead to the modified version of the Audacity interface, start watching the video at about 11 minutes. 

If anyone is interested in it further, feel free to email me (There is actually a whole paper being published on it at the moment).

Brett Park

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Focus Plus Context Audacity Demo (screencast)

Martyn Shaw-2
Hi Brett

Very interesting!  I take it the 'zoomed-in' region has a constant
relative zoom compared to the rest?

Martyn

Brett Park wrote:

> I recently did a presentation on a new interface concept for editing
> audio. The concept involves something called Focus-Plus-Context interfaces.
> Anyways, you can check out the screencast at  
> <http://www.research.parknation.com/index.php>
> http://www.research.parknation.com/index.php 
>
> The screencast goes through and explains Focus Plus Context
> in leman terms. The video is about 13 minutes. But, if you just want to
> skip ahead to the modified version of the Audacity interface, start
> watching the video at about 11 minutes.
>
> If anyone is interested in it further, feel free to email me (There is
> actually a whole paper being published on it at the moment).
>
> Brett Park
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Focus Plus Context Audacity Demo (screencast)

Gale Andrews
In reply to this post by Brett Park-2

| From Brett Park <[hidden email]>
| Fri, 11 Apr 2008 23:11:07 -0600
| Subject: [Audacity-devel] Focus Plus Context Audacity Demo (screencast)
> I recently did a presentation on a new interface concept for editing audio.
> The concept involves something called Focus-Plus-Context interfaces.
> Anyways, you can check out the screencast at
> http://www.research.parknation.com/index.php 
>

Hi Brett

Interesting. I did nonetheless find it a bit hard to tell what time
point I was at in the zoomed in (green) section. I don't think the
Selection Bar gave any clue, it did not seem to vary when you
scrolled through the green area? Also the horizontal ruler  
either side of the green area sometimes seemed to lose its time
markings altogether to the right of the area.

Would the Apple screen magnifier idea you featured be feasible?
That would seem a bit more intuitive to me, giving you a small
"lens" showing you the context position over the main waveform,
and then the magnified section in a freely movable magnification
window.  

Thanks again.


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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Focus Plus Context Audacity Demo (screencast)

Brett Park-2
In reply to this post by Martyn Shaw-2

> Hi Brett
>
> Very interesting!  I take it the 'zoomed-in' region has a constant
> relative zoom compared to the rest?

It depends on the setting that is used. The focal area is currently  
always a constant zoom, however, the areas immediately adjacent on the  
left and right can have different smoothing options applied to the  
transition area. For example, I have four options:

No Transition

Liner (Zoom: 111111112345555555543211111111)

Layered (Zoom: 111111112222555588888888888888555522221111111111)

Or an logarithmic verions (the one shown in the video (Zoom  
1111111111111248 16 16 16 16 16 16 8 4 2 11111111) or something like  
that

It actually gets quite complex because whenever the zoom level of the  
focal area is changed, we have to recalculate the whole other zooms in  
order to make it fit in the window.

Brett

>
>
> Martyn
>
> Brett Park wrote:
>> I recently did a presentation on a new interface concept for editing
>> audio. The concept involves something called Focus-Plus-Context  
>> interfaces.
>> Anyways, you can check out the screencast at
>> <http://www.research.parknation.com/index.php>
>> http://www.research.parknation.com/index.php
>>
>> The screencast goes through and explains Focus Plus Context
>> in leman terms. The video is about 13 minutes. But, if you just  
>> want to
>> skip ahead to the modified version of the Audacity interface, start
>> watching the video at about 11 minutes.
>>
>> If anyone is interested in it further, feel free to email me (There  
>> is
>> actually a whole paper being published on it at the moment).
>>
>> Brett Park
>>

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Focus Plus Context Audacity Demo (screencast)

Brett Park-2
In reply to this post by Gale Andrews

>
> | From Brett Park <[hidden email]>
> | Fri, 11 Apr 2008 23:11:07 -0600
> | Subject: [Audacity-devel] Focus Plus Context Audacity Demo  
> (screencast)
>> I recently did a presentation on a new interface concept for  
>> editing audio.
>> The concept involves something called Focus-Plus-Context interfaces.
>> Anyways, you can check out the screencast at
>> http://www.research.parknation.com/index.php
>>
>
> Hi Brett
>
> Interesting. I did nonetheless find it a bit hard to tell what time
> point I was at in the zoomed in (green) section. I don't think the
> Selection Bar gave any clue, it did not seem to vary when you
> scrolled through the green area? Also the horizontal ruler
> either side of the green area sometimes seemed to lose its time
> markings altogether to the right of the area.
>

Yeah, the ruler still needs some work, I still don't have the best  
idea on how the ruler works. I was just trying to make sure the time  
was right. During the focal area, the ruler doesn't currently mark the  
time at smaller intervals (which would be a lot more helpful). Perhaps  
when I get time in the future.

> Would the Apple screen magnifier idea you featured be feasible?
> That would seem a bit more intuitive to me, giving you a small
> "lens" showing you the context position over the main waveform,
> and then the magnified section in a freely movable magnification
> window.


Hmmm, Interesting idea. That would definitely work for viewing,  
however, I think there may be some problems with editing. As a side  
note, if you hold down the f key, the focal area will always be  
centered on the cursor, providing a feature similar to what you are  
talking about. Perhaps I will try your idea in the future. Thanks


>
>
> Thanks again.
>
>
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Focus Plus Context Audacity Demo (screencast)

Martyn Shaw-2


Brett Park wrote:
>> | From Brett Park <[hidden email]>
>> | Fri, 11 Apr 2008 23:11:07 -0600
>> | Subject: [Audacity-devel] Focus Plus Context Audacity Demo  
>> (screencast)
...

>> Interesting. I did nonetheless find it a bit hard to tell what time
>> point I was at in the zoomed in (green) section. I don't think the
>> Selection Bar gave any clue, it did not seem to vary when you
>> scrolled through the green area? Also the horizontal ruler
>> either side of the green area sometimes seemed to lose its time
>> markings altogether to the right of the area.
>>
>
> Yeah, the ruler still needs some work, I still don't have the best  
> idea on how the ruler works. I was just trying to make sure the time  
> was right. During the focal area, the ruler doesn't currently mark the  
> time at smaller intervals (which would be a lot more helpful). Perhaps  
> when I get time in the future.

I noticed your 'transition area'.  Cool.

If you haven't already, you might like to look at the way the ruler
works in TimeTrack::Draw, (I was playing with this just earlier
today).  The envelope is used in
    mRuler->Draw(dc, GetEnvelope(), GetRangeLower(), GetRangeUpper());
and in the ruler code to 'warp' the ruler.

If you haven't tried the 'time track' already then maybe this will help:
Load some audio.
Tracks -> Add New... -> Time Track.
'Down arrow' on Time Track -> Set Range... -> Lower 100, enter, Upper 500.
Envelope tool.
Now set the 'time' envelope at the top of the track by setting a point
at (say) 2s.  Then set another just after 2s at the bottom, another at
3s at the bottom and a final one at 3s at the top. (These times refer
to the main / original ruler, not the one in the Time Track!  This can
be confusing at first!)
Selection tool.
Zoom in to about 1.9s - 2.3s on the main ruler.
You should see the Time Track ruler having a variable scale.  The
section from 2-3s should go at 5 times the speed and have
correspondingly smaller increments.

In terms of the ruler, I think this is very similar to what you want
with 'No Transition', the other cases should follow.  I'm guessing
that you didn't use a 'Envelope' to implement the changes to the
display of the waveform but there should be some compatibility here?

HTH
Martyn

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Meter Range

Gale Andrews

Hi Martyn

I noticed when we made the minimum display range apply to the
meters as well as the Waveform dB view, we changed the default to
the new -60dB value, which was the minimum display of the
meters under the old system. I wonder if -36dB might not be a
better default? This was the old default for Waveform dB (which I
think was chosen as best for high amplitude editing). Also - 36dB
might be more beneficial for the meters too, given their rather small
default size in 1.3.4. This would give more discrimination at the top
end where it matters, and make the minor ticks and a meaningful
"-12" (rather than only "0") visible without dragging it out.


Thanks

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Meter Range

Martyn Shaw-2
Hi Gale

I think 0 -> -60dB has always been the fixed range, so I set the
default to that to avoid controversy.

I think that a 36dB range is probably too small, unless working on a
really noisy system.  Most systems will have a noise floor well below
that.  I think a meter is most use if you can see both the peak and
the noise floor when recording, then you know if your signal is within
the dynamic range of the system.

The system I have here has the noise on the mike input (with nothing
plugged in and the gain turned all the way up) at about -80dB, so I
really need the 96dB range to use the meters properly.

In the end, different people want different things and now they can at
least select what they want.

Martyn

Gale Andrews wrote:

> Hi Martyn
>
> I noticed when we made the minimum display range apply to the
> meters as well as the Waveform dB view, we changed the default to
> the new -60dB value, which was the minimum display of the
> meters under the old system. I wonder if -36dB might not be a
> better default? This was the old default for Waveform dB (which I
> think was chosen as best for high amplitude editing). Also - 36dB
> might be more beneficial for the meters too, given their rather small
> default size in 1.3.4. This would give more discrimination at the top
> end where it matters, and make the minor ticks and a meaningful
> "-12" (rather than only "0") visible without dragging it out.
>
>
> Thanks
>
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Meter Range

Gale Andrews

| From Martyn Shaw <[hidden email]>
| Thu, 17 Apr 2008 21:28:38 +0100
| Subject: [Audacity-devel] Meter Range

> I think 0 -> -60dB has always been the fixed range, so I set the
> default to that to avoid controversy.
>
> I think that a 36dB range is probably too small, unless working on a
> really noisy system.  Most systems will have a noise floor well below
> that.  I think a meter is most use if you can see both the peak and
> the noise floor when recording, then you know if your signal is within
> the dynamic range of the system.
>
> The system I have here has the noise on the mike input (with nothing
> plugged in and the gain turned all the way up) at about -80dB, so I
> really need the 96dB range to use the meters properly.
>
> In the end, different people want different things and now they can at
> least select what they want.

Hi Martyn

I agree about the meter range, having played around a bit more. And
even for playback, a long fade-out that's still audible doesn't register
on the meter at -36db minimum. No doubt "someone" out there will
want to combine the old defaults (-36 dB waveform view and -60 dB
meters) but linking the two values is more logical.

I understand that where the ticks/values on the meter and waveform
vertical scale appear is a matter of judgement, but I still can't help
feeling there aren't enough on either meter or waveform at -60dB
without dragging. Does the default meter size leave more space
than necessary to right of it? For example at 1024 x 768 I can
move the Edit Toolbar to right of it and still have space to expand
the meter enough to show a very useful tick at -10dB. At 800 x 600
the meter has more space to right of it than is needed for the only
item (transcription toolbar) that could fit alongside.


Thanks


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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Meter Range

Martyn Shaw-2


Gale Andrews wrote:
...
> I agree about the meter range, having played around a bit more. And
> even for playback, a long fade-out that's still audible doesn't register
> on the meter at -36db minimum. No doubt "someone" out there will
> want to combine the old defaults (-36 dB waveform view and -60 dB
> meters) but linking the two values is more logical.

At some point we could have separate prefs, but let's leave it as is
for now.

> I understand that where the ticks/values on the meter and waveform
> vertical scale appear is a matter of judgement, but I still can't help
> feeling there aren't enough on either meter or waveform at -60dB
> without dragging.

I have made a slight improvement to the ruler, and I think that the
minimum distance allowed between minor ruler ticks could usefully  be
made smaller.  What do you think?  Try changing the '16' on line 379
of Ruler.cpp to '10' say, and recompile - at many sizes of the ruler
you will get closer spaced ticks.

The vertical ruler on the 'Waveform (dB)' is a different type, it uses
  RealFormat rather than LinearDBFormat (line 355 of TrackArtist.cpp).
  Try changing it and see what you think - I am inclined to think it
should be LinearDBFormat and I don't know why RealFormat was chosen
back in 2003.  Shall we change it?

  Does the default meter size leave more space
> than necessary to right of it? For example at 1024 x 768 I can
> move the Edit Toolbar to right of it and still have space to expand
> the meter enough to show a very useful tick at -10dB. At 800 x 600
> the meter has more space to right of it than is needed for the only
> item (transcription toolbar) that could fit alongside.

The meter displays at it's minimum size by default.  We could make
that bigger, but that may upset some users I guess.  I don't know how
to make it display bigger by default but resizeable downwards.  Sorry.

TTFN
Martyn

>
>
> Thanks
>
>
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Meter Range

Gale Andrews

| From Martyn Shaw <[hidden email]>
| Sat, 19 Apr 2008 23:32:18 +0100
| Subject: [Audacity-devel] Meter Range
> Gale Andrews wrote:
> > I agree about the meter range, having played around a bit more. And
> > even for playback, a long fade-out that's still audible doesn't register
> > on the meter at -36db minimum. No doubt "someone" out there will
> > want to combine the old defaults (-36 dB waveform view and -60 dB
> > meters) but linking the two values is more logical.
>
> At some point we could have separate prefs, but let's leave it as is
> for now.

Hi Martyn

I don't know the work involved, but I think it would be a higher
priority to have a preference to enable waveform (dB) view as
default. As it is now, people who want to use this view have got
to turn it on in each session. Or, have Audacity remember this in
the .cfg file like it remembers things like toolbar positions.

 

> > I understand that where the ticks/values on the meter and waveform
> > vertical scale appear is a matter of judgement, but I still can't help
> > feeling there aren't enough on either meter or waveform at -60dB
> > without dragging.
>
> I have made a slight improvement to the ruler,
>
> and I think that the > minimum distance allowed between minor ruler
> ticks could usefully  be
> made smaller.  What do you think?  Try changing the '16' on line 379
> of Ruler.cpp to '10' say, and recompile - at many sizes of the ruler
> you will get closer spaced ticks.
>
> The vertical ruler on the 'Waveform (dB)' is a different type, it uses
> RealFormat rather than LinearDBFormat (line 355 of TrackArtist.cpp).
> Try changing it and see what you think - I am inclined to think it
> should be LinearDBFormat and I don't know why RealFormat was chosen
> back in 2003.  Shall we change it?

First, I updated with your modification to Ruler.cpp without changing
Ruler.cpp or TrackArtist.cpp. At the default -60dB preference I get
12dB spaced ticks on the meter and a number "-24" visible. So this
is an improvement I think, though "-12" on the meter would still be
nice.

Then I made your suggested modifications to the two files. The Waveform
(dB) view now has 12dB spaced ticks and "-24" and "-48" visible. Much
better. Did this arise solely from using LinearDBFormat, or as a result
of changing the Ruler.cpp value from 16? The meter ticks and values
are the same as building without the two modifications.    

Value "10" in Ruler.cpp does create a ruler display inconsistency after
a three minute track was opened and I started zooming: with the "10"
value, one particular zoom stage gives you 0.0, 1.0 ... through to 9.0,
then no 10 value and odd values 11.0, 13.0, 15.0. With the Ruler.cpp
value at 16, you get 0.0, 1.0 ... consistently through to 16.0.

I also tried value "8" in Ruler.cpp which made no difference to the
above inconsistency, but it greatly increased the ticks in the default ruler
at launch with no track open. I don't myself have any real complaints
about the ticks on the ruler, so perhaps it means choosing some other
value in Ruler.cpp or leaving as it is?

I stumbled across a minor problem with the Waveform (dB) view that isn't
in the 1.3.4 release but is in a CVS build I made just before you made
your ruler modification on the 19th April. If you have a track open then
drag it upwards to make it less tall, it starts to "shiver" horizontally
about one-quarter through the drag, but stops if you carry on dragging
up. Does not occur with Waveform view. The builds I made with your
mod on the 19th and then with the Ruler.cpp and TrackArtist.cpp changes
added in all also have this "shiver". Sorry if this is known, but I don't
recall it.

> > Does the default meter size leave more space
> > than necessary to right of it? For example at 1024 x 768 I can
> > move the Edit Toolbar to right of it and still have space to expand
> > the meter enough to show a very useful tick at -10dB. At 800 x 600
> > the meter has more space to right of it than is needed for the only
> > item (transcription toolbar) that could fit alongside.
>
> The meter displays at it's minimum size by default.  We could make
> that bigger, but that may upset some users I guess.  I don't know how
> to make it display bigger by default but resizeable downwards.  

If you look at the much greater default length of the meters in 1.2.6
compared to 1.3.4, I don't think complaints about the 1.3.4 meters
being too long are very likely. There definitely have been some
adverse comments about the short length in comparison to 1.2.6.  


Thanks

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Meter Range

Martyn Shaw-2


Gale Andrews wrote:

> | From Martyn Shaw <[hidden email]>
> | Sat, 19 Apr 2008 23:32:18 +0100
> | Subject: [Audacity-devel] Meter Range
>> Gale Andrews wrote:
>>> I agree about the meter range, having played around a bit more. And
>>> even for playback, a long fade-out that's still audible doesn't register
>>> on the meter at -36db minimum. No doubt "someone" out there will
>>> want to combine the old defaults (-36 dB waveform view and -60 dB
>>> meters) but linking the two values is more logical.
>> At some point we could have separate prefs, but let's leave it as is
>> for now.
>
> Hi Martyn
>
> I don't know the work involved, but I think it would be a higher
> priority to have a preference to enable waveform (dB) view as
> default. As it is now, people who want to use this view have got
> to turn it on in each session. Or, have Audacity remember this in
> the .cfg file like it remembers things like toolbar positions.

Fair enough, I guess.  Could be a pref but not a remeberence of
previous settings, since it is selected on a track-by-track basis (and
so would have to go in the project file).  Maybe this should go on our
list of feature requests?

>>> I understand that where the ticks/values on the meter and waveform
>>> vertical scale appear is a matter of judgement, but I still can't help
>>> feeling there aren't enough on either meter or waveform at -60dB
>>> without dragging.
>> I have made a slight improvement to the ruler,
>>
>> and I think that the > minimum distance allowed between minor ruler
>> ticks could usefully  be
>> made smaller.  What do you think?  Try changing the '16' on line 379
>> of Ruler.cpp to '10' say, and recompile - at many sizes of the ruler
>> you will get closer spaced ticks.
>>
>> The vertical ruler on the 'Waveform (dB)' is a different type, it uses
>> RealFormat rather than LinearDBFormat (line 355 of TrackArtist.cpp).
>> Try changing it and see what you think - I am inclined to think it
>> should be LinearDBFormat and I don't know why RealFormat was chosen
>> back in 2003.  Shall we change it?
>
> First, I updated with your modification to Ruler.cpp without changing
> Ruler.cpp or TrackArtist.cpp. At the default -60dB preference I get
> 12dB spaced ticks on the meter and a number "-24" visible. So this
> is an improvement I think,

Good, so we'll leave this in then.

  though "-12" on the meter would still be
> nice.

but there just isn't space, without the bits of text all running into
each other (so the algorithm decided).

> Then I made your suggested modifications to the two files. The Waveform
> (dB) view now has 12dB spaced ticks and "-24" and "-48" visible. Much
> better. Did this arise solely from using LinearDBFormat, or as a result
> of changing the Ruler.cpp value from 16? The meter ticks and values
> are the same as building without the two modifications.    

For the future, it's always best to make on change and test it, rather
than making 2 at a time!

The change to -12, -24 etc come from changing to LinearDBFormat.  In
dB mode we use steps of 3, 6, 9, 12 etc whereas in Real we use 1, 2,
5, 10, 20 etc.

The difference in meter ticks by changing "16" to "10" in Ruler.cpp
becomes obvious as you increase the horizontal size of the meter or
vertical size of the "Waveform (dB)" track.  "10" causes the switch to
adding minor units sooner (closer spaced).


> Value "10" in Ruler.cpp does create a ruler display inconsistency after
> a three minute track was opened and I started zooming: with the "10"
> value, one particular zoom stage gives you 0.0, 1.0 ... through to 9.0,
> then no 10 value and odd values 11.0, 13.0, 15.0. With the Ruler.cpp
> value at 16, you get 0.0, 1.0 ... consistently through to 16.0.

Which ruler are you talking about here?  Horizontal or vertical?  With
what range?  Once the ticks sizes are decided on the text is put in if
it fits.  Missing labels are because they won't fit in.  Presumably
here 10.0 didn't fit, so it was missed out, then the others do.  This
is tricky code and probably varies on different platforms.

> I also tried value "8" in Ruler.cpp which made no difference to the
> above inconsistency, but it greatly increased the ticks in the default ruler
> at launch with no track open. I don't myself have any real complaints
> about the ticks on the ruler, so perhaps it means choosing some other
> value in Ruler.cpp or leaving as it is?

"16" has worked for years.  I was just experimenting.  Getting more
minor ticks looks useful to me.  I'll leave it as-is for now.

> I stumbled across a minor problem with the Waveform (dB) view that isn't
> in the 1.3.4 release but is in a CVS build I made just before you made
> your ruler modification on the 19th April. If you have a track open then
> drag it upwards to make it less tall, it starts to "shiver" horizontally
> about one-quarter through the drag, but stops if you carry on dragging
> up. Does not occur with Waveform view. The builds I made with your
> mod on the 19th and then with the Ruler.cpp and TrackArtist.cpp changes
> added in all also have this "shiver". Sorry if this is known, but I don't
> recall it.

I'm not sure what you mean here.  Is it the space dedicated to the
ruler that is changing?  That is part of EXPERIMENTAL_RULER_AUTOSIZE
that I (experimentally) turned on recently (16/4/8) in Experimental.h.
  It may have bugs that need investigating, but I haven't seen any yet.

>>> Does the default meter size leave more space
>>> than necessary to right of it? For example at 1024 x 768 I can
>>> move the Edit Toolbar to right of it and still have space to expand
>>> the meter enough to show a very useful tick at -10dB. At 800 x 600
>>> the meter has more space to right of it than is needed for the only
>>> item (transcription toolbar) that could fit alongside.
>> The meter displays at it's minimum size by default.  We could make
>> that bigger, but that may upset some users I guess.  I don't know how
>> to make it display bigger by default but resizeable downwards.  
>
> If you look at the much greater default length of the meters in 1.2.6
> compared to 1.3.4, I don't think complaints about the 1.3.4 meters
> being too long are very likely. There definitely have been some
> adverse comments about the short length in comparison to 1.2.6.  

I have 1.2.6 here (according to 'about') but don't know if I'm seeing
the default view.  I have a meter about the same size as HEAD default,
a major label at 0 and a minor one at -21 (I think), lots of ticks at
3dB intervals, I can undock the meter but not re-dock it...

Critically, the size is about the same.  What are you seeing?

TTFN
Martyn

> Thanks
>
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Meter Range

Gale Andrews

| From Martyn Shaw <[hidden email]>
| Mon, 21 Apr 2008 01:12:27 +0100
| Subject: [Audacity-devel] Meter Range

> > | From Martyn Shaw <[hidden email]>
> > | Sat, 19 Apr 2008 23:32:18 +0100
> > | Subject: [Audacity-devel] Meter Range
> >> Gale Andrews wrote:
> > I don't know the work involved, but I think it would be a higher
> > priority to have a preference to enable waveform (dB) view as
> > default. As it is now, people who want to use this view have got
> > to turn it on in each session. Or, have Audacity remember this in
> > the .cfg file like it remembers things like toolbar positions.
>
> Fair enough, I guess.  Could be a pref but not a remeberence of
> previous settings, since it is selected on a track-by-track basis (and
> so would have to go in the project file).  Maybe this should go on our
> list of feature requests?

"Add preference to permit Waveform (dB) display to be enabled on launch"
is a "deemed priority after 1.4" in "Release Checklist not aiming". That
is, we were hoping at one stage to do it for 1.4, but it was demoted.  

> >> I have made a slight improvement to the ruler,
> >> and I think that the minimum distance allowed between minor ruler
> >> ticks could usefully  be
> >> made smaller.  What do you think?  Try changing the '16' on line 379
> >> of Ruler.cpp to '10' say, and recompile - at many sizes of the ruler
> >> you will get closer spaced ticks.
> >>
> >> The vertical ruler on the 'Waveform (dB)' is a different type, it uses
> >> RealFormat rather than LinearDBFormat (line 355 of TrackArtist.cpp).
> >> Try changing it and see what you think - I am inclined to think it
> >> should be LinearDBFormat and I don't know why RealFormat was chosen
> >> back in 2003.  Shall we change it?
> >
> > First, I updated with your modification to Ruler.cpp without changing
> > Ruler.cpp or TrackArtist.cpp. At the default -60dB preference I get
> > 12dB spaced ticks on the meter and a number "-24" visible. So this
> > is an improvement I think,
>
> Good, so we'll leave this in then.
>
>   though "-12" on the meter would still be nice.
>
> but there just isn't space, without the bits of text all running into
> each other (so the algorithm decided).

Well the algorithm may be right (my eye suggests it is a tight fit?),
but an easy fit if the meter default size was a bit larger.


> > Then I made your suggested modifications to the two files. The Waveform
> > (dB) view now has 12dB spaced ticks and "-24" and "-48" visible. Much
> > better. Did this arise solely from using LinearDBFormat, or as a result
> > of changing the Ruler.cpp value from 16? The meter ticks and values
> > are the same as building without the two modifications.    
>
> For the future, it's always best to make on change and test it, rather
> than making 2 at a time!

Agree. I built the version with the CVS change on its own but did not
think about the other two changes being separate somehow. Beginner's
error (OK if you learn from them)... but in this case you knew the
answer anyway so I could afford to be lazy =:)
 
> The change to -12, -24 etc come from changing to LinearDBFormat.  In
> dB mode we use steps of 3, 6, 9, 12 etc whereas in Real we use 1, 2,
> 5, 10, 20 etc.
>
> The difference in meter ticks by changing "16" to "10" in Ruler.cpp
> becomes obvious as you increase the horizontal size of the meter or
> vertical size of the "Waveform (dB)" track.  "10" causes the switch to
> adding minor units sooner (closer spaced).

Understood perfectly - thanks.

>
> > Value "10" in Ruler.cpp does create a ruler display inconsistency after
> > a three minute track was opened and I started zooming: with the "10"
> > value, one particular zoom stage gives you 0.0, 1.0 ... through to 9.0,
> > then no 10 value and odd values 11.0, 13.0, 15.0. With the Ruler.cpp
> > value at 16, you get 0.0, 1.0 ... consistently through to 16.0.
>
> Which ruler are you talking about here?  Horizontal or vertical?  With
> what range?  Once the ticks sizes are decided on the text is put in if
> it fits.  Missing labels are because they won't fit in.  Presumably
> here 10.0 didn't fit, so it was missed out, then the others do.  This
> is tricky code and probably varies on different platforms.

Sorry, I mean the horizontal ruler.  But we're on the same platform,
so if you changed the Ruler.cpp value to 10, I'd assume you would
see the same. Importing a three minute track and doing three zooms
ought to be a common scenario. It does not look very good if that is
replicable.  


> > I also tried value "8" in Ruler.cpp which made no difference to the
> > above inconsistency, but it greatly increased the ticks in the default ruler
> > at launch with no track open. I don't myself have any real complaints
> > about the ticks on the ruler, so perhaps it means choosing some other
> > value in Ruler.cpp or leaving as it is?
>
> "16" has worked for years.  I was just experimenting.  Getting more
> minor ticks looks useful to me.  I'll leave it as-is for now.

Unless someone disagrees, I think changing to LinearDBFormat for the
vertical ruler looks better. Do you think we should commit that?

I also agree getting more minor ticks is useful too. When I have time
I'll try "12" in Ruler.cpp (with no change in Track Artist) and let you
know how it looks.  


>
> > I stumbled across a minor problem with the Waveform (dB) view that isn't
> > in the 1.3.4 release but is in a CVS build I made just before you made
> > your ruler modification on the 19th April. If you have a track open then
> > drag it upwards to make it less tall, it starts to "shiver" horizontally
> > about one-quarter through the drag, but stops if you carry on dragging
> > up. Does not occur with Waveform view. The builds I made with your
> > mod on the 19th and then with the Ruler.cpp and TrackArtist.cpp changes
> > added in all also have this "shiver". Sorry if this is known, but I don't
> > recall it.
>
> I'm not sure what you mean here.  Is it the space dedicated to the
> ruler that is changing?  That is part of EXPERIMENTAL_RULER_AUTOSIZE
> that I (experimentally) turned on recently (16/4/8) in Experimental.h.
> It may have bugs that need investigating, but I haven't seen any yet.

Did you try with the steps I gave (slowly dragging up the track to squash
it vertically)? I am looking at it now. The entire ruler and the waveform
are moving left to right by about half an inch at about five cycles per
second).
   

> >>> Does the default meter size leave more space
> >>> than necessary to right of it? For example at 1024 x 768 I can
> >>> move the Edit Toolbar to right of it and still have space to expand
> >>> the meter enough to show a very useful tick at -10dB. At 800 x 600
> >>> the meter has more space to right of it than is needed for the only
> >>> item (transcription toolbar) that could fit alongside.
> >> The meter displays at it's minimum size by default.  We could make
> >> that bigger, but that may upset some users I guess.  I don't know how
> >> to make it display bigger by default but resizeable downwards.  
> >
> > If you look at the much greater default length of the meters in 1.2.6
> > compared to 1.3.4, I don't think complaints about the 1.3.4 meters
> > being too long are very likely. There definitely have been some
> > adverse comments about the short length in comparison to 1.2.6.  
>
> I have 1.2.6 here (according to 'about') but don't know if I'm seeing
> the default view.  I have a meter about the same size as HEAD default,
> a major label at 0 and a minor one at -21 (I think), lots of ticks at
> 3dB intervals, I can undock the meter but not re-dock it...
>
> Critically, the size is about the same.  What are you seeing?

Well I'm going for "default" on what happens if I delete the Windows
registry key. After I then launch Audacity and choose language for first
run, I see:
http://www.gaclrecords.org.uk/0035.png

And when I maximise the window, the meters seem to be the same
large size but now fitted top right:
http://www.gaclrecords.org.uk/0036.png

Since 1.2.6 can't remember the meter toolbar undocked position
I'm puzzled why you get such a small meter size on launch.

Thanks

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Meter Range

Martyn Shaw-2


Gale Andrews wrote:
...
>> but there just isn't space, without the bits of text all running into
>> each other (so the algorithm decided).
>
> Well the algorithm may be right (my eye suggests it is a tight fit?),
> but an easy fit if the meter default size was a bit larger.

True, of course. See below (near the bottom).

...

>>> Value "10" in Ruler.cpp does create a ruler display inconsistency after
>>> a three minute track was opened and I started zooming: with the "10"
>>> value, one particular zoom stage gives you 0.0, 1.0 ... through to 9.0,
>>> then no 10 value and odd values 11.0, 13.0, 15.0. With the Ruler.cpp
>>> value at 16, you get 0.0, 1.0 ... consistently through to 16.0.
>> Which ruler are you talking about here?  Horizontal or vertical?  With
>> what range?  Once the ticks sizes are decided on the text is put in if
>> it fits.  Missing labels are because they won't fit in.  Presumably
>> here 10.0 didn't fit, so it was missed out, then the others do.  This
>> is tricky code and probably varies on different platforms.
>
> Sorry, I mean the horizontal ruler.  But we're on the same platform,
> so if you changed the Ruler.cpp value to 10, I'd assume you would
> see the same. Importing a three minute track and doing three zooms
> ought to be a common scenario. It does not look very good if that is
> replicable.  

OK, now I see what you mean, and deduce that you must have Audacity at
  just less than 800px wide?  That's when this happens here at least.
  Since the single digits are narrower, they fit but only every-other
2 digit number will.  I believe that it will vary with platform
because the fonts are different.  It clearly varies with the size of
the main window etc..  10 is too small!

...
> Unless someone disagrees, I think changing to LinearDBFormat for the
> vertical ruler looks better. Do you think we should commit that?

Yes, but I don't know what others think.  Maybe I'll just put it in
and see what happens!

> I also agree getting more minor ticks is useful too. When I have time
> I'll try "12" in Ruler.cpp (with no change in Track Artist) and let you
> know how it looks.  

OK.

>>> I stumbled across a minor problem with the Waveform (dB) view that isn't
>>> in the 1.3.4 release but is in a CVS build I made just before you made
>>> your ruler modification on the 19th April. If you have a track open then
>>> drag it upwards to make it less tall, it starts to "shiver" horizontally
>>> about one-quarter through the drag, but stops if you carry on dragging
>>> up. Does not occur with Waveform view. The builds I made with your
>>> mod on the 19th and then with the Ruler.cpp and TrackArtist.cpp changes
>>> added in all also have this "shiver". Sorry if this is known, but I don't
>>> recall it.
>> I'm not sure what you mean here.  Is it the space dedicated to the
>> ruler that is changing?  That is part of EXPERIMENTAL_RULER_AUTOSIZE
>> that I (experimentally) turned on recently (16/4/8) in Experimental.h.
>> It may have bugs that need investigating, but I haven't seen any yet.
>
> Did you try with the steps I gave (slowly dragging up the track to squash
> it vertically)? I am looking at it now. The entire ruler and the waveform
> are moving left to right by about half an inch at about five cycles per
> second).

OK, now I see it.  I was a bit slow last night perhaps.  And it isn't
a minor problem - the CPU usage goes up to over 50% here when this is
happening!  There is obviously a loop of redraw big, redraw small,
redraw big... going on as part of EXPERIMENTAL_RULER_AUTOSIZE.  I'm
going to turn that off again and make a note about it in
Experimental.h while I have a think about it.  Shame, that's a
retrograde step for zoomed in Spectrum view.

...

>> I have 1.2.6 here (according to 'about') but don't know if I'm seeing
>> the default view.  I have a meter about the same size as HEAD default,
>> a major label at 0 and a minor one at -21 (I think), lots of ticks at
>> 3dB intervals, I can undock the meter but not re-dock it...
>>
>> Critically, the size is about the same.  What are you seeing?
>
> Well I'm going for "default" on what happens if I delete the Windows
> registry key. After I then launch Audacity and choose language for first
> run, I see:
> http://www.gaclrecords.org.uk/0035.png
>
> And when I maximise the window, the meters seem to be the same
> large size but now fitted top right:
> http://www.gaclrecords.org.uk/0036.png
>
> Since 1.2.6 can't remember the meter toolbar undocked position
> I'm puzzled why you get such a small meter size on launch.

Nice pictures!  I don't know why we are seeing different things, and I
don't really want to trawl through CVS to find out when/how it was
changed.  Instead, why not try changing the default size of the meter
and see what you think?  In MeterToolBar.cpp, change the '99' in lines
79 and 88 to, say, 150 and see if it is better for you.  I am not
inclined to make these too large as it restricts the minimum size for
the meters and, as I said before, some people may only want little meters.

TTFN
Martyn

> Thanks
>
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Meter Range

Gale Andrews
In reply to this post by Gale Andrews

| From Gale Andrews <[hidden email]>
| Mon, 21 Apr 2008 18:32:05 +0100
| Subject: [Audacity-devel] Meter Range
> I'll try "12" in Ruler.cpp (with no change in TrackArtist.cpp) and let you
> know how it looks.  

I get the same problem with the missing "10.0" in the horizontal ruler.
I'm happier to go with changing  'Waveform (dB)' to use LinearDBFormat.
That makes a real difference to that dB default view without breaking
anything else I've noticed.

 
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Meter Range

Gale Andrews
In reply to this post by Martyn Shaw-2

| From Martyn Shaw <[hidden email]>
| Tue, 22 Apr 2008 00:15:44 +0100
| Subject: [Audacity-devel] Meter Range
 > >>> Value "10" in Ruler.cpp does create a ruler display inconsistency after

> >>> a three minute track was opened and I started zooming: with the "10"
> >>> value, one particular zoom stage gives you 0.0, 1.0 ... through to 9.0,
> >>> then no 10 value and odd values 11.0, 13.0, 15.0. With the Ruler.cpp
> >>> value at 16, you get 0.0, 1.0 ... consistently through to 16.0.
> >> Which ruler are you talking about here?  Horizontal or vertical?  With
> >> what range?  Once the ticks sizes are decided on the text is put in if
> >> it fits.  Missing labels are because they won't fit in.  Presumably
> >> here 10.0 didn't fit, so it was missed out, then the others do.  This
> >> is tricky code and probably varies on different platforms.
> >
> > Sorry, I mean the horizontal ruler.  But we're on the same platform,
> > so if you changed the Ruler.cpp value to 10, I'd assume you would
> > see the same. Importing a three minute track and doing three zooms
> > ought to be a common scenario. It does not look very good if that is
> > replicable.  
>
> OK, now I see what you mean, and deduce that you must have Audacity at
> just less than 800px wide?  
> That's when this happens here at least.
> Since the single digits are narrower, they fit but only every-other
> 2 digit number will.  I believe that it will vary with platform
> because the fonts are different.  It clearly varies with the size of
> the main window etc..  10 is too small!

Hi Martyn

No, I had Audacity maximised at 1024 x 768, normal (96) dpi and
reproduced this every time on a three minute imported track. However
I have Tahoma as the system font which has wider than normal
characters. If that choice affects the ruler, it might be the explanation.  

> >> I have 1.2.6 here (according to 'about') but don't know if I'm seeing
> >> the default view.  I have a meter about the same size as HEAD default,
> >> a major label at 0 and a minor one at -21 (I think), lots of ticks at
> >> 3dB intervals, I can undock the meter but not re-dock it...
> >>
> >> Critically, the size is about the same.  What are you seeing?
> >
> > Well I'm going for "default" on what happens if I delete the Windows
> > registry key. After I then launch Audacity and choose language for first
> > run, I see:
> > http://www.gaclrecords.org.uk/0035.png
> >
> > And when I maximise the window, the meters seem to be the same
> > large size but now fitted top right:
> > http://www.gaclrecords.org.uk/0036.png
> >
> > Since 1.2.6 can't remember the meter toolbar undocked position
> > I'm puzzled why you get such a small meter size on launch.
>
> Nice pictures!  I don't know why we are seeing different things, and I
> don't really want to trawl through CVS to find out when/how it was
> changed.  Instead, why not try changing the default size of the meter
> and see what you think?  In MeterToolBar.cpp, change the '99' in lines
> 79 and 88 to, say, 150 and see if it is better for you.  I am not
> inclined to make these too large as it restricts the minimum size for
> the meters and, as I said before, some people may only want little
> meters.

I tried values of "120" and "140". "120" does not change the number of
ticks or the values displayed (0 and 24) but looks a good compromise
for size and (at 1024 x 1068) still lets me get the Edit toolbar
alongside it. "140" gives me values of "0, 12, 24 and 36" (same number
of ticks) but I can't fit Edit Toolbar alongside.

It looks like I need about a value of "130" in MeterToolBar to get
"12" as well as "0" and "24" on the meter (with the current
algorithm), but that stops me getting Edit Toolbar alongside at  
1024 x 768).

No other toolbar will dock alongside at 800 x 600 even at a
value of "120", but on the whole I think a change to 120 - 140
would be sensible, especially given higher resolutions than
1024 x 768 are not uncommon now.



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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: Meter Range

Martyn Shaw-2
OK, I've set the minimum meter width to 130px so we get at least a few
numbers on the scale at minimum size.  It was 99 since Leland
introduced MeterToolBar.cpp on 16/09/2006).

This gives us, out of the box,
http://mjshaw.at-uclan.com/audacity/windowplus000.png
and the possibility of at least this at 640x480 (which I think we are
still supporting?)
http://mjshaw.at-uclan.com/audacity/windowplus001.png

I figure this will bother hardly anybody, but if it does just give us
a shout.

Martyn

Gale Andrews wrote:

...

>> changed.  Instead, why not try changing the default size of the meter
>> and see what you think?  In MeterToolBar.cpp, change the '99' in lines
>> 79 and 88 to, say, 150 and see if it is better for you.  I am not
>> inclined to make these too large as it restricts the minimum size for
>> the meters and, as I said before, some people may only want little
>> meters.
>
> I tried values of "120" and "140". "120" does not change the number of
> ticks or the values displayed (0 and 24) but looks a good compromise
> for size and (at 1024 x 1068) still lets me get the Edit toolbar
> alongside it. "140" gives me values of "0, 12, 24 and 36" (same number
> of ticks) but I can't fit Edit Toolbar alongside.
>
> It looks like I need about a value of "130" in MeterToolBar to get
> "12" as well as "0" and "24" on the meter (with the current
> algorithm), but that stops me getting Edit Toolbar alongside at  
> 1024 x 768).
>
> No other toolbar will dock alongside at 800 x 600 even at a
> value of "120", but on the whole I think a change to 120 - 140
> would be sensible, especially given higher resolutions than
> 1024 x 768 are not uncommon now.
>
>
>
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel