Re: [Audacity-devel] libaudacity

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

Joshua,

>>This library would probably use wxBase at first, which
>>is the non-GUI part of wxWindows, but later we could
>>remove this dependency.
> 
> In favor of what?  It the STL satisfactorily portable?  Or would we be
> re-implementing strings, arrays, and stacks?

It depends on what we actually need.  That's why I want
to start by using wxBase.

> On the subject of naming, how will we refer to these parts?  What is
> "Audacity?"  Is it engine, or the combination of the engine and UI?  What
> is the default wxWindows UI called?  If I started writing a BeOS GUI,
> would it be Audacity?  If Matt and I started working on Python bindings,
> what would they be called?

Good question.

Maybe we need a name for the engine, kind of like "Gecko" for Mozilla.
For now I'll use libaudacity to refer to the engine / non-gui parts.

>>  Sequence      A self-contained class which manages the low-level
>>                  implementation of a sequence of audio samples
>>                  using reference-counted blocks on disk.  In other
>>                  words, this would be all of the low-level methods
>>                  that used to be in WaveTrack - the building
>>                  blocks that make fast Copy, Paste, & Undo possible.
>>  WaveTrack     A non-GUI class, inheriting from Track, which
>>                  implements operations such as Cut, Copy and Paste,
>>                  loading, and saving for WaveTracks.  Uses a
>>                  Sequence class to actually do the manipulations.
>>                  Would include new methods which help the GUI
>>                  classes render the waveform on the screen, without
>>                  actually drawing it: for example, a method which
>>                  returns the upper and lower coordinates of each
>>                  vertical line in the waveform, given a starting
>>                  time and a zoom level.

> I don't quite understand how WaveTrack and Sequence are divided.  Will
> WaveTrack.Cut() just be a wrapper around mSequence->Cut()?

A Sequence keeps track of a list of samples, from 0 to n-1.  It
abstracts an interface that makes you think that it really has
an array of length n in memory, when in reality the samples are
on disk.

A WaveTrack understands that the samples are at a sample rate, they
have an offset, and that there may be other attributes like a gain
control, an amplitude envelope, and a channel.

When you select Cut or Copy, most of the hard work is done by
the Sequence.  However, you ask a WaveTrack to Cut the data
between 2.000 and 3.500 seconds - the WaveTrack converts this
to samples, and tells the Sequence to extract the samples
between 88200 and 153350 and put them in a new Sequence.

> I assume the engine will still have the concept of a project?  Right now
> AudacityProject tightly couples the GUI of the project window with the
> concept a project.  How will you divide this?

That's a good question.  I haven't totally worked this out.

I'm tempted to say that to libaudacity, there is no project, just
a DirManager and a list of tracks.  The list of tracks represents
the world, and the DirManager represents a place to store all of
their data.

I think this will work at first.  However, later on we may need
to separate out the GUI and non-GUI portions of the project.

We won't need to separate this out in order to build command-line
programs which essentially deal with one project at a time,
or our test suite, but we will want to separate it when we start
on other complete audio editors based on libaudacity.

> How does spectrogram mode work?  It seems that there is no higher-level
> description of the data than the pixel level, unlike waveform mode which
> you can describe in terms of lines.

There's a slightly higher-level description: for each pixel along the
x-axis, it's a constant-size array representing the spectrum at that
point in time, independent of the vertical size of the track.  In other
words, if the FFT size is 512, then every pixel would have 256 values.
The TrackDisplay would resize this array to the current vertical size
of the track, and render it in color or grayscale.

> I hope you can think of a higher-level way to handle linked tracks than
> we have right now.  The way it is now, every method anywhere in Audacity
> that deals with tracks has to know about and respect the "Linked" status
> of tracks, which is easy to forget or get wrong.

One idea is that we actually create an entire Track called a
StereoTrack.  This track has two WaveTracks as members, and every
time you call an operation on it, it passes the operation along
to its two member tracks.  To every other part of the program, it
just sees another Track and doesn't realize there are really two inside.

This generalizes to a TrackGroup later on.  We could have hierarchies
of tracks!

> I'm interested in whatever you want to divvy out.  I would be happy
> writing any of these classes.

Great!

- Dominic