Shane Mueller <smueller@...> wrote:
> On Tue, 2002-10-29 at 15:20, Vaughan Johnson wrote:
>
> > Here are a couple of things I thought of. I'm still a novice user.
> >
> > * I'm not sure of the terminology, but I know "cursor" in Audacity
> > is a single time point selection, and it's great that it or the
> > selection range shows up in the status bar. What's the Audacity
> > name for the little triangle & moving vertical line that show
> > what's currently being played? Maybe it's because I'm not yet
> > swift enough on navigation, but it seems to me it would be good to
> > show that current time value in the status bar, too. Especially if
> > you're not auto-scrolling while playing, it could help finding
> > something you hear and want to focus on. Updating it in the status
> > bar shouldn't take much processing -- but could be another option
> > in the Interface Prefs.
>
> > * History: I love that history window. How about adding more
> > details, like which effect instead of "Applied an effect", maybe
> > with parameters?
> This sounds like a great little project. One issue with this is that
> the code for this would be distributed throughout the program, and isn't
> isolated in one class.
What kind of code could be isolated? Creating an undo state only consists
of:
PushState("Performed some operation");
This can be made more specific with something like:
PushState(wxString::Format("Applied %fms of reverb", seconds))
But I don't see anything that is abstraction-friendly.
Also, I wonder how much specificity is useful. I think it would be great
to see "Amplified by 3db", but I think that you could get carried away,
supplying more information than is really useful.
Don't get me wrong though, I think it's a great project too. Another good
project related to the history window would be to rewrite the last two
procedures in Track.cpp without using std::set, since we can't use stuff out of
the STL. These are the procedures that allow the history window to display how
much disk space each operation took. This would be kind of complicated though.
> * Add a pause button (actually, this would be kinda tricky, and might
> require mucking with AudioIO)
Actually, it would be easy if you just modified the callback to produce
silence if the "pause" state was toggled. This would make it extremely
responsive, since you wouldn't have to actually act on the physical stream
at all.
Josh
--
"Only Angels can sing that high, and only dogs can hear it." -- James Evans
|
