audacity-devel

[Audacity-devel] editing markers - user comments/ suggestions

[matt yee-k. <ye...@no...>]

Hello!

I've been doing some editing in audacity on the powerpc-linux platform.
i've been using the 1.1 branch from cvs. The program runs great - good
work guys!. 

I've got a couple of suggestions re: markers and looping. I'm a bit of
an ex-sound forge fan - had to drop it now i'm on a linux mission. I
love the way that markers work in sound forge and think some of this
could work well in audacity. . 

marker/ loop features that would be good...(not in order of importance) 

1. markers can be dropped from a keyboard shortcut whilst playing sound
files. 
2. markers can be moved/ deleted with the mouse or their numerical
values can be edited directly. 
3. double clicking between 2 markers selects the data between those
markers
4. there are 2 playback modes, looped and non looped. In looped mode,
the current selection is looped. (great for cutting loops out of tracks)
or the whole file, if theres no selection. non-looped playback mode is
just like the current audacity playback. 

hope these suggestions are useful.

cheers

matthew

-- 
:::::::::::::::::::::::::::

 Matthew Yee-King
 ye...@no...
 http://www.yeeking.net/
 
:::::::::::::::::::::::::::

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Matt B. <mbr...@cs...>]

On Apr 22, matt yee-king wrote:

> I've been doing some editing in audacity on the powerpc-linux platform.
> i've been using the 1.1 branch from cvs. The program runs great - good
> work guys!.

Excellent!  Another Matt using powerpc-linux.  :)

Be careful using the CVS code.  We have at least one known crashing bug
(triggered by scrolling any track all the way off screen).  The code is also
changing frequently, and several features are only partially implemented.
I do use 1.1 builds for my own work, since they work better with the powermac
sound drivers.

We'll be interested in any bug reports or feedback from you.

> 1. markers can be dropped from a keyboard shortcut whilst playing sound
> files.
> 2. markers can be moved/ deleted with the mouse or their numerical
> values can be edited directly.
> 3. double clicking between 2 markers selects the data between those
> markers
> 4. there are 2 playback modes, looped and non looped.

These are all things we would like to do.  We haven't started work on them
yet, but they will definitely happen sometime in the future.

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Joshua H. <jha...@up...>]

Hi Matt, thanks for writing.

* matt yee-king (ye...@no...) wrote:
> I've got a couple of suggestions re: markers and looping. I'm a bit of
> an ex-sound forge fan - had to drop it now i'm on a linux mission. I
> love the way that markers work in sound forge and think some of this
> could work well in audacity. . 
> 
> marker/ loop features that would be good...(not in order of importance) 
>
> 1. markers can be dropped from a keyboard shortcut whilst playing sound
> files. 
> 2. markers can be moved/ deleted with the mouse or their numerical
> values can be edited directly. 
> 3. double clicking between 2 markers selects the data between those
> markers
> 4. there are 2 playback modes, looped and non looped. In looped mode,
> the current selection is looped. (great for cutting loops out of tracks)
> or the whole file, if theres no selection. non-looped playback mode is
> just like the current audacity playback. 

Since this is being directly requested by a user, I'd like to take this
on soon.  Could we brainstorm ideas for how the GUI should function?
That way when I have time I can refer back and implement the ideas that
are suggested.

For dropping markers during playback, how would Audacity decide which
label track to place the marker in?

How should labels be edited (name and value)?  A pop-up dialog seems
cumbersome. 

For the "double clicking selects data between markers," how do you decide
which label track's markers to use?

How should looped and non-looped modes be toggled?

On the subject of UI design, Should there be more status fields in
Audacity's project window?  For example, cool edit has several, and a
giant field for the current time (?)

   http://www.syntrillium.com/cooledit/view.xfl?img=screenshot_ce2kmain.gif

> hope these suggestions are useful.

They definitely are, thank you for taking the time to chime in.

Joshua

-- 
Joshua Haberman  <jo...@ha...>

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Anthony A. O. <Ant...@ep...>]

On Wed, 24 Apr 2002 00:48:59 -0700, Joshua Haberman wrote:


>Since this is being directly requested by a user, I'd like to take this
>on soon.  Could we brainstorm ideas for how the GUI should function?
>That way when I have time I can refer back and implement the ideas that
>are suggested.

>For dropping markers during playback, how would Audacity decide which
>label track to place the marker in?

Audacity can have multiple Labeltracks. That'll get interesting.


>How should labels be edited (name and value)?  A pop-up dialog seems
>cumbersome. 

That's where most applications have slight problems, so they implement a marker
list window. Mostly you'll have to target a small thing in the marker in the
timeline or marker line(Protools) to edit it, but that list makes it a little
easier. Labeltracks don't behave very nice anyway. Perhaps a we should keep
markers outside these in a new track object that sits above the timeline perhaps
?

Protools : Hit Enter on the keypad anytime to define a marker. Escape cancels
the marker def. The popup dialog simply requests a piece of text, that uses a
standard text control(unlike the current Labeltrack). Hit Return to complete the
naming. Defaults are "Marker x" x is an integer that gets ++ everytime. The
marker window offer a LOT more though. I could try to get a screenshot.

Popular behaviour is Enter,Enter to quickly set a marker.
Protools features a marker list that can be sorted alphabetically and by
timeline.


Soundforge : Shorcut "m". Doesn't give you the opportunity to name them during
creation but is fast. This is a two-track editor though. Has a marker
list(inc.region markers)

Both systems can edit markers graphically, though it takes a little targetting,
since they're small.

Protools lets you delete markers by dragging them above their timeline(like our
envelope points though that's not convenient for those). Soundforge lets you
right-click to get options(GoTo,Edit,Delete,Update). I have included a
screenshot(small 4kB PNG) of this.


>For the "double clicking selects data between markers," how do you decide
>which label track's markers to use?

By not using Labeltracks, or if you want to select between two Labels(which
shouldn't be the new markers I think), the user should double click in to the
Labeltrack and thus get the selection between two labels in that Labeltrack.


>How should looped and non-looped modes be toggled?

Shortcut on Soundforge 6 is "Q". Very handy! It also has a small icon on the
very left of the toolbar to switch this behaviour. In Soundforge 5- this used to
be a playmode. Protools has many options here(Pre-,Postroll looping playback and
recording for starters).
A switch for now might be a great idea, right next to the playback
controls(w/shortcut too). Looprecording could get interesting once we have
regions instead of onefile/track. It's great for overdubbing.


>On the subject of UI design, Should there be more status fields in
>Audacity's project window?  For example, cool edit has several, and a
>giant field for the current time (?)

As can be seen on the Soundforge screenshot(ignore the playback controls) there
are three fields at the bottom (cursor position, selection start & end). THe
1:8.192 is the ZOOM ratio, which I think is good to have.

Protools has one more, which Cooledit has too, but at the top of the screen.
Namely the length of the current selection. Question is, do we need to know the
start, end and length of the current view as well ? Where would we put it ?

 TOny

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Joshua H. <jha...@up...>]

* Anthony Airon Oetzmann (Ant...@ep...) wrote:
> On Wed, 24 Apr 2002 00:48:59 -0700, Joshua Haberman wrote:
> 
> 
> >Since this is being directly requested by a user, I'd like to take this
> >on soon.  Could we brainstorm ideas for how the GUI should function?
> >That way when I have time I can refer back and implement the ideas that
> >are suggested.
> 
> >For dropping markers during playback, how would Audacity decide which
> >label track to place the marker in?
> 
> Audacity can have multiple Labeltracks. That'll get interesting.

Both you and Matt (Yee-King) find it strange to have labels contained in
tracks (of which there can be several).  Should we work with this idea,
or should we build them into the editing window like other editors do?  I
suppose a third choice would be to keep them in a label track, but only
allow one label track per project.

> >How should labels be edited (name and value)?  A pop-up dialog seems
> >cumbersome. 
> 
> That's where most applications have slight problems, so they implement a marker
> list window. Mostly you'll have to target a small thing in the marker in the
> timeline or marker line(Protools) to edit it, but that list makes it a little
> easier. Labeltracks don't behave very nice anyway. Perhaps a we should keep
> markers outside these in a new track object that sits above the timeline perhaps
> ?
> 
> Protools : Hit Enter on the keypad anytime to define a marker. Escape cancels
> the marker def. The popup dialog simply requests a piece of text, that uses a
> standard text control(unlike the current Labeltrack). Hit Return to complete the
> naming. Defaults are "Marker x" x is an integer that gets ++ everytime. The
> marker window offer a LOT more though. I could try to get a screenshot.

A screenshot would be nice.

I mean to start working on more advanced marker functionality soon.  Are
we calling them markers or labels, by the way?  Are these two terms
interchangable?

Joshua

-- 
Joshua Haberman  <jo...@ha...>

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Shane M. <smu...@um...>]

> Both you and Matt (Yee-King) find it strange to have labels contained in
> tracks (of which there can be several).  Should we work with this idea,
> or should we build them into the editing window like other editors do?  I
> suppose a third choice would be to keep them in a label track, but only
> allow one label track per project.

Just to announce my intentions because it seems relevant at this point,
I am planning in the not-too-distant future to modify the label track to
make it more conducive to audio coding applications.  This will probably
include making the output files be compliant with the "PRAAT" program's
format, some interface issues, and allowing both "point" labels (as are
currently available" and "interval" labels (they have a beginning and an
end, and text can be placed within this region). One issue with these
type of applications is how to associate a transcription track with a
particular sound track. One possibility, which would address the above
problem, would be to allow (but not require) a label track to be linked
to a audio track. Then, you can create a label track associated with the
sound track you want to split apart (it will appear linked to the track,
like stereo tracks do now), and the 'split track at labels' function
will only be accessed via the label track menu. (and only the label
track menu of 'attached' labels). Functionality to attach and detach
label tracks from sound tracks would also be possible.

Other operations that are similar to the split at labels function could
be useful at that point.  For instance, someone may have recorded a
conversation between two people, and use an interval label track to
designate when one person is talking, and another track to designate
when the second person is. Then, a useful operation would be to 'Remove
audio outside interval labels', so you can hear only one side of the
conversation.

Anyway, keep this in mind if you want to continue to use label tracks as
a method for splitting audio tracks.

Stm...

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Dominic M. <do...@mi...>]

Regarding label tracks:

I don't see any reason to support more than one label track
for now.

Please consider the existing label tracks as nothing more
than a quick proof-of-concept - I hacked them together in
a couple of evenings more than a year ago.  It might be
best to start over from scratch, rather than working with
what's there.

I think it would be really neat if labels were more like
"guides" in Photoshop or the Gimp.  If you're not familiar
with guides, open the Gimp, create a new image, and then
click in the ruler and drag into the window.  A guide
appears under the mouse - it's like a straight horizontal
or vertical dotted line.  Everything you do snaps to the
nearest guide from then on.  You can move a guide, or you
can delete it by dragging it out of the window.

I'd love to have labels work the same way, though there
should be more ways to create a label.  But I think
it'd be great if labels worked like guides (i.e. they
draw a straight line all the way through all of the
tracks, and selections would automatically snap to
the nearest label).  Then the actual text of the label
could appear just under the ruler, instead of in a
separate track.

To generalize: Audacity currently has three types of tracks:
wavetracks, notetracks, and labeltracks.  However, Audacity
only works with wavetracks very well.  Therefore for the
time being we should probably redesign the UI so that
there's only one type of track (wave i.e. audio tracks)
and that all of the other features are centered around
that.  Later on, if we ever add decent MIDI support, we
can make notetracks full-fledged tracks again, etc.

- Dominic

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Joshua H. <jha...@up...>]

* Dominic Mazzoni (do...@mi...) wrote:
> I think it would be really neat if labels were more like
> "guides" in Photoshop or the Gimp.  If you're not familiar
> with guides, open the Gimp, create a new image, and then
> click in the ruler and drag into the window.  A guide
> appears under the mouse - it's like a straight horizontal
> or vertical dotted line.  Everything you do snaps to the
> nearest guide from then on.  You can move a guide, or you
> can delete it by dragging it out of the window.
> 
> I'd love to have labels work the same way, though there
> should be more ways to create a label.  But I think
> it'd be great if labels worked like guides (i.e. they
> draw a straight line all the way through all of the
> tracks, and selections would automatically snap to
> the nearest label).  Then the actual text of the label
> could appear just under the ruler, instead of in a
> separate track.

This sounds like the scheme used by ProTools, based on the screenshot
Tony sent:

   http://www.reverberate.org/files/protoolsfree-stuff.png

I like this system.  However, this seems to be at odds with the plans
Shane has for enhancing the current label track system.  How shall we
proceed?

Joshua

-- 
Joshua Haberman  <jo...@ha...>

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Shane M. <smu...@um...>]

> This sounds like the scheme used by ProTools, based on the screenshot
> Tony sent:
> 
>    http://www.reverberate.org/files/protoolsfree-stuff.png
> 
> I like this system.  However, this seems to be at odds with the plans
> Shane has for enhancing the current label track system.  How shall we
> proceed?
There are a few possibilities.  The thing is, I don't see the functions
performed by a 'label' track and a 'marker' track as serving the same
purpose.  The functional overlap is minimal, especially because the
'marker' track doesn't need to have text in it. <rant mode on>Creating a
user interface based on programmatic requirements is one of the
usability sins of software, and occurs in open source software all the
time (check out any linux cd burner--they all are built modeling the
underlying command-line tool, rather than modeling what the user wants
to accomplish.  Consequently, the most usable linux cd burners are the
command-line tools.)<rant mode off>. 

My point here is that we should look at what the intended problem the
feature addresses, and how the user could easily solve the problem. The
use of a label track to allow track splitting makes the user have to do
a series of operations that do not make obvious sense: 1. create a new
track called a "label" track, 2. create labels (which want a text
description, but don't use them in this case), 3. interpret these labels
as markers, 4. Select the label track and another track, and 5. use the
menu to perform track splitting. I think that this feature got to be the
way it is because it is a simple way to achieve the intended
functionality, based on the current program structure, user requests,
and how the functionality has been able to be done manually in the past.
This is similar to how I added stereo track resizing, which works ok,
but was motivated more by program structure than the user's naive needs
(which Dominic kindly pointed out.) But neither enables the
functionality in a way that is easily discovered or even obvious
post-hoc.

What I suggest is the following:

Implement "Markers" similar to the protools scheme. Make markers part of
the ruler, just like tab markers are part of the ruler of word
processors. Maybe a vertical dashed line could be laid across all tracks
to indicate the presence of a marker, but then you have to worry about
whether they should be draggable, and how to distinguish them from the
other horizontal lines that can already exist on tracks. Under this
scheme, a 'marker' track will ALWAYS be present, but ONLY one will ever
be present. These markers would not have any text on them, but they
probably would not need text on them. The 'split track at markers'
option becomes part of a track menu, rather than the main menu. In my
opinion, The label track can stay as it is, as well as the 'split track
at labels', because this is a reasonable thing someone might want to do
if they were actually using label tracks to transcribe audio tracks. 
With a little TLC (which I plan to give it this summer), it could be
really useful for me and some of my colleagues.

That is my suggestion. Comments? Would this be difficult? It would also
be good to list some OTHER functions that markers could serve, so that
we have a better chance of getting it right from the beginning. Like:

Drag-Snap functionality
???? What else?

And determine little interface things:
	How to get rid of them (double click?)
	How to move them around (click-drag on ruler)
	What cursor to use when you are on top of a marker (???)
	What tool modes they should be available in  (all of them???)
	etc.

Stm...

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Dominic M. <do...@mi...>]

Shane,

Your logic makes sense.  It sounds like it would be better, for
now, to enable track markers in the ruler, and to leave the
label tracks alone.  The label tracks could use some work too,
but that's more orthogonal to your goals with the markers.

> That is my suggestion. Comments? Would this be difficult? It would also
> be good to list some OTHER functions that markers could serve, so that
> we have a better chance of getting it right from the beginning. Like:

This doesn't sound too difficult.  Let me know if anything
seems kludgy when you try to implement it, and I can help
you refactor existing code.

> Drag-Snap functionality

How about a "quantize" option which only lets you put
markers at even boundaries, for example 1 second boundaries,
or on beat boundaries once we support rulers in beats.

> And determine little interface things:

Play with the Gimp to see a good example of how this can
be done well.

> 	How to get rid of them (double click?)

Much better: click and drag them out of the window.
Also a menu option to remove all guides.

> 	How to move them around (click-drag on ruler)

Yes, or click-drag anywhere in the guide which is not over
top of a track.  The cursor should change to a left-right
arrow.

> 	What cursor to use when you are on top of a marker (???)

A hand, or a left-right arrow.

> 	What tool modes they should be available in  (all of them???)

All of them, but never when you're over top of a track.  Only when
you're over top of the ruler or between tracks, or below tracks.

- Dominic

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Anthony A. O. <Ant...@ep...>]

On Sat, 04 May 2002 12:18:00 -0700, Dominic Mazzoni wrote:

>> Drag-Snap functionality

>How about a "quantize" option which only lets you put
>markers at even boundaries, for example 1 second boundaries,
>or on beat boundaries once we support rulers in beats.

You've described the Grid mode of most apps. Logic enables this
by default btw and it works quite brilliantly. Once you guys
make a grid mode happen, you may want to think about tempo
markers to change that grid in the session(for live stuff
for example...). It'll only make sense with MIDI though. Long
way off I guess.



>> And determine little interface things:

>Play with the Gimp to see a good example of how this can
>be done well.

>> 	How to get rid of them (double click?)
>
>Much better: click and drag them out of the window.
>Also a menu option to remove all guides.
>
>> 	How to move them around (click-drag on ruler)
>
>Yes, or click-drag anywhere in the guide which is not over
>top of a track.  The cursor should change to a left-right
>arrow.

This would copy the drag-to-change-selection cursor. I guess this
is easily changed, so we could test al suggestions pretty easily.

 Take care
  Tony

[Audacity-devel] Windows latency and a nascent QA test suite

[Shane T. M. <smu...@um...>]

I did a little more poking around, and am seeing these latency issues on
both a win98 and a win2k system. They don't exist for the current .98
stable release, but do exist for a fresh compile of CVS head and the i18
release available on the translation website. My totally clueless guess
would be that it was caused either by the cursor-follows-playback fix or
the new sampling depths. Anyone have a better guess?

The basic effect is this: when you select something and hit "play", the
play cursor tracks immediately, but the sounds it tracks are delayed by
200-400 msecs after they are supposed to be heard. But, I think playing
stops when the cursor gets to the end of the selection. If you don't
select a big enough chunk, you won't hear anything, because playing will
stop before it starts.

---

I don't like the way these things sneak up on us, and have been
thinking about some way to get a better handle on these things for a while
now.  On and off, I have been compiling a set of comprehensive QA tests
for Audacity. Basically, it's just a checklist of everything in the
application and how it should work. Currently, some aspects are more
complete than others, but I don't have the time to do this properly, so I
haven't brought it up before now.  It would be a good project for one or
two users to spearhead, and could be a good way to "leverage" our large
and grateful user base, especially to help insure that the next stable
release is as good as possible.  I'll commit what I have so far into a /qa
directory just to make working on them easier, and to allow others to make
changes if you want. But, I'm not expecting anything to happen with them
unless some motivated volunteer(s) come forth looking to help.

A general roadmap of what would need to be done would be:
  1) One or more (probably non-programmer) volunteers come forward and
spearhead this.

  2) Test cases involving all major and minor components get written and
organized.

  3) Some type of system for recording and collating different test
results developed (maybe via sourceforge tracker).

  4) More user volunteers solicited on a semi-regular basis to take
current builds on relevant platforms and determine which test cases
pass and which fail.

If this happens, it will make it easier to determine when some
 problem was first detected (e.g., "I see that stereo reverb effect worked
on April 31, but by May 19 it was broken). It could also help provide more
concrete release goals, and help determine when l10/i18 issues arise. That
is...if it is done well and organized by someone who is really on the
ball.  If it isn't done well, it could become burdensome busy-work,
similar to my checkbook register:  it never really tells me how much money
I have, it is usually outdated, when it isn't outdated it is often wrong,
and it causes me to expend a bunch of extra effort.

Let's say I'm optimistically skeptical about the value of these tests. If
people come volunteering to help with the line "I'm no good at
programming, but I'd like to help", maybe someone could suggest this as a
project to contribute to. And in the meantime, you current developers
might consider fleshing out one or more areas you are familiar with and
care about--I'll be occasionally doing that myself, but not in a serious
or dedicated fashion.  (N.B.: the pass/fail info shouldn't be kept in
these files, just an instruction about an operation to perform and the
intended result)

Stm...

Re: [Audacity-devel] Windows latency and a nascent QA test suite

[Dominic M. <do...@mi...>]

Shane,

The audio code has been totally rewritten from scratch between
version 0.98 and the new 1.1 branch.  The old code used native
audio I/O routines that Roger and I wrote from scratch, whereas
now we use PortAudio.  PortAudio is still young and evolving,
but I think the API is very good (and improving) and there are
lots of people banging on it, which can only benefit us.

I'm guessing that either there's a bug in the Windows version
of PortAudio, or we're not calling it correctly.  I'll look
into it soon.

I like your idea of the testing suite.  Basically just a
checklist of things to do to make sure that Audacity works.
I do think that we'll get volunteers to help us with these,
especially if we divide it into smaller, more manageable
chunks.  One idea would be to make a web interface for
this list, allowing users to fill out a web form where
they can check off the features that do and don't work,
and add comments.

It would be nice if we could automate as many tests as
possible.  Obviously some things can't be automated - like
drawing glitches and audio I/O glitches.  But a lot of
other things could be automated - so it would be great if
we could write some unit tests.

The Benchmark dialog is a step in that direction.  It
tests not only the speed, but also the correctness of the
low-level WaveTrack operations.  Basically it simulates
someone opening a long track and cutting and pasting
on it for a while.

There are a lot of other things we could test that way.

In terms of priorities, I'd like us to focus on getting
versions 1.0 and 1.1 out the door first.  Neither of
them have to be perfect.  Version 1.0 should be stable
and consistent, and I believe it is, based on the
extremely low number of bug reports we've received
about version 0.98 (and many of these have been fixed).

After this huge release, and the web site overhaul,
we can plan on doing new releases of the 1.1 branch
far more often.  Once a month would be fine with me.
That will help get the user community involved,
because they won't have to wait as long to see the
bugs they report fixed.

- Dominic

Shane Thomas Mueller wrote:
> I did a little more poking around, and am seeing these latency issues on
> both a win98 and a win2k system. They don't exist for the current .98
> stable release, but do exist for a fresh compile of CVS head and the i18
> release available on the translation website. My totally clueless guess
> would be that it was caused either by the cursor-follows-playback fix or
> the new sampling depths. Anyone have a better guess?
> 
> The basic effect is this: when you select something and hit "play", the
> play cursor tracks immediately, but the sounds it tracks are delayed by
> 200-400 msecs after they are supposed to be heard. But, I think playing
> stops when the cursor gets to the end of the selection. If you don't
> select a big enough chunk, you won't hear anything, because playing will
> stop before it starts.
> 
> ---
> 
> I don't like the way these things sneak up on us, and have been
> thinking about some way to get a better handle on these things for a while
> now.  On and off, I have been compiling a set of comprehensive QA tests
> for Audacity. Basically, it's just a checklist of everything in the
> application and how it should work. Currently, some aspects are more
> complete than others, but I don't have the time to do this properly, so I
> haven't brought it up before now.  It would be a good project for one or
> two users to spearhead, and could be a good way to "leverage" our large
> and grateful user base, especially to help insure that the next stable
> release is as good as possible.  I'll commit what I have so far into a /qa
> directory just to make working on them easier, and to allow others to make
> changes if you want. But, I'm not expecting anything to happen with them
> unless some motivated volunteer(s) come forth looking to help.
> 
> A general roadmap of what would need to be done would be:
>   1) One or more (probably non-programmer) volunteers come forward and
> spearhead this.
> 
>   2) Test cases involving all major and minor components get written and
> organized.
> 
>   3) Some type of system for recording and collating different test
> results developed (maybe via sourceforge tracker).
> 
>   4) More user volunteers solicited on a semi-regular basis to take
> current builds on relevant platforms and determine which test cases
> pass and which fail.
> 
> If this happens, it will make it easier to determine when some
>  problem was first detected (e.g., "I see that stereo reverb effect worked
> on April 31, but by May 19 it was broken). It could also help provide more
> concrete release goals, and help determine when l10/i18 issues arise. That
> is...if it is done well and organized by someone who is really on the
> ball.  If it isn't done well, it could become burdensome busy-work,
> similar to my checkbook register:  it never really tells me how much money
> I have, it is usually outdated, when it isn't outdated it is often wrong,
> and it causes me to expend a bunch of extra effort.
> 
> Let's say I'm optimistically skeptical about the value of these tests. If
> people come volunteering to help with the line "I'm no good at
> programming, but I'd like to help", maybe someone could suggest this as a
> project to contribute to. And in the meantime, you current developers
> might consider fleshing out one or more areas you are familiar with and
> care about--I'll be occasionally doing that myself, but not in a serious
> or dedicated fashion.  (N.B.: the pass/fail info shouldn't be kept in
> these files, just an instruction about an operation to perform and the
> intended result)
> 
> Stm...
> 
> 
> _______________________________________________________________
> 
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> Audacity-devel mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Remco P. <rjp...@ho...>]

On 2002.05.04 20:53 Shane Mueller wrote:

> There are a few possibilities.  The thing is, I don't see the functions
> performed by a 'label' track and a 'marker' track as serving the same
> purpose.  The functional overlap is minimal, especially because the
> 'marker' track doesn't need to have text in it.

I think markers do need text. In case you have a big wave file and a lot 
of markers, it's nice to look at a marker and read that it marks the 
beginning of some speech. Or that it marks the end of some music. When I 
edit my wave files, I often have a choice where to start and end the 
tracks that will finally make it to the cd. I mark all possibilities and 
listen to the different selections that I have. It would be nice if I 
could add some text that indicates what possibility that marker marks.

That you don't need text to split up a wave file doesn't mean that text at 
markers is useless.

In my opinion markers should be able to be placed over the whole project, 
using the time ruler or something and they should be placed using a 
label-sort-of-track and be connected to some wave tracks (as was suggested 
elsewhere in the many replies).

Remco Poelstra

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Joshua H. <jha...@up...>]

* Shane Mueller (smu...@um...) wrote:
> My point here is that we should look at what the intended problem the
> feature addresses, and how the user could easily solve the problem. The
> use of a label track to allow track splitting makes the user have to do
> a series of operations that do not make obvious sense: 1. create a new
> track called a "label" track, 2. create labels (which want a text
> description, but don't use them in this case), 3. interpret these labels
> as markers, 4. Select the label track and another track, and 5. use the
> menu to perform track splitting.

I think the problem is that I (mistakenly?) assumed that the labels in a
label track were designed to be equivalent to markers.  If you make this
assumption as I did, I think the "split at labels" feature makes sense.
Also, it does use the text description: it uses it for the name of the
new track that is created, which I thought was a friendly thing to do.

> Implement "Markers" similar to the protools scheme. Make markers part of
> the ruler, just like tab markers are part of the ruler of word
> processors. Maybe a vertical dashed line could be laid across all tracks
> to indicate the presence of a marker, but then you have to worry about
> whether they should be draggable, and how to distinguish them from the
> other horizontal lines that can already exist on tracks. Under this
> scheme, a 'marker' track will ALWAYS be present, but ONLY one will ever
> be present. These markers would not have any text on them, but they
> probably would not need text on them.

Why wouldn't they have text?  I think it could be useful, and the
ProTools screenshot shows that ProTools has text associated with the
markers.

> That is my suggestion. Comments? Would this be difficult?

I think it's a good idea.  But what is the different between markers and
labels if we have both?  What is the difference in purpose that we can
explain to the user?

The next two weeks are finals for me, so I shouldn't do any work on
Audacity (though I probably will anyway :-).  After finals, I would like to
write marker functionality, if no one else has started on it yet.  Other
things on my plate are:

* rewriting command-line exporting to use libsndfile
* revisit mp3 exporting, investigating reports of corrupted exporting
  and incompatible windows versions of the lame dll.

Joshua

-- 
Joshua Haberman  <jo...@ha...>

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Anthony A. O. <Ant...@ep...>]

On 04 May 2002 14:53:04 -0400, Shane Mueller wrote:


>Drag-Snap functionality
>???? What else?


>And determine little interface things:
>	How to get rid of them (double click?)

Vegas and Soundforge do it in a way I don't like. THey make you access a
right-click menu(context sensitive menu) and find the delete entry. Horrible and
slow.

Protools simply makes you drag the marker above its ruler. The second option(in
all apps) is to delete them in the marker list window. This is a way I favor and
use heavily.

When the drag-above-ruler method is used, the cursor turns in to a little
trashcan. Nice touch and very intuitive, if the user knows about this. Maybe
click-holding on a marker could grey out a larger area above the marker and blit
a larger trashcan image on top for the duration of the click-hold, so a user
would instantly know that the marker can be gotten rid of that way(what an
expression).

The marker grabbing is acompanied by a finger-pointing-hand cursor in all apps.
Very intuitive and you should also consider defining the area where you can grab
a marker a little larger than the graphics of the marker. If you're going to
give the markers their own ruler (VERY recommended folks, take it from a guy
that swears his monitors every day and Digidesign for lesser design fault),
there's precious little you could do there besides grab markers (or mark a bunch
of 'em to move them around :).


>	How to move them around (click-drag on ruler)

a)Point,click-hold,move,release. 
b)double-click opens properties(accessible from marker list window too of
  course) to change marker position to time code by hand. Easy edit controls
  for time code.


>	What cursor to use when you are on top of a marker (???)

Hand with pointed finger upwards. If anyone has a better idea, please do
spill the beans. The finger works quite well, though I'd apreciate the
marker changing colour when being dragged.


>	What tool modes they should be available in  (all of them???)

Any, because you're mucking around in the marker ruler, not in a track.

If anyone wants to hear about practical uses of simple markers,
region markers, CD track markers(Vegas has these for burning from
inside the app - we could do SPLIT markers!) or loop markers,
let me know.
I've used simple markers (Augan OMX-24 -> one button to set at cursor,
one button to delete marker nearest to cursor and of course(!!!!!!)
buttons to jump back and forth betwen markers. Handy stuff if it has
a purpose and anonymous markers like these(no text) are cool so very
simple things. We used one for scene changes, two for sound hickups
and three for fx-to-be-inserted spots. It's fast and simple.

Markers with text have one distinct advantage. They provide readable
stucture.

Do you want text and non-text markers ? Make 'em look different, but
keep the make/unmake marker functions easier to do for non-text markers,
such as one button per function.

For text markers, the Protools method is simple, fast[you can just hit
enter(keypad),return for quick marker setting] and easy to manage,
because the marker list can be sorted by timecode and marker name.

Tune in next week for 'Markers from the Black Lagune' ...

 Tony

Re: [Audacity-devel] editing markers - user comments/ suggestions

[Anthony A. O. <Ant...@ep...>]

On Sun, 05 May 2002 02:21:32 +0200, Anthony Airon Oetzmann wrote:

>Protools simply makes you drag the marker above its ruler. The second option(in
>all apps) is to delete them in the marker list window. This is a way I favor and
>use heavily.

These are ways I favor heavily. I use the marker window only when skipping
around larger stuff. Temporary markers are discarded with the drag method. 'Tis
faster.

 Tony