[sugar] Journal integration design for Measure Activity

Albert Cahalan acahalan
Mon Oct 22 12:40:27 EDT 2007

On 10/22/07, Eben Eliason <eben.eliason at gmail.com> wrote:
> On 10/22/07, Albert Cahalan <acahalan at gmail.com> wrote:
> > On 10/22/07, Eben Eliason <eben.eliason at gmail.com> wrote:
> > > On 10/21/07, Albert Cahalan <acahalan at gmail.com> wrote:
> >
> > > > The simplest format for audio data is an audio file.
> > > > Basic *.wav data is really simple. It's a 44-byte header
> > > > followed by the raw data.
> > >
> > > Obviously I know little about the .wav format, so perhaps you are
> > > right.  My only point is that, as far as I understand it, the logs are
> > > really just a list of samples (time, value), which are at least a
> > > second apart.  Is there really a reason to use an audio format for
> > > what amounts to a simple list of tuples?
> >
> > I don't see this data as being tuples at all.
> > It's not even x-y data.
> >
> > Timing is perfectly regular. Doing an FFT on irregularly
> > spaced data is awkward, though possible.
> >
> > Audio file converters already exist. Loading and storing is fast.
> > The storage is efficient.
> Well, then it's a list of values (with a known sample rate).  Still, I
> don't see this as audio.  What harm is there in making it a text file
> which ANY text editor could open?  Moreover, treating it as audio data
> is going to group it as under a search for all things of type "Audio",
> which it isn't.  I wouldn't expect my graph of the past week's daily
> temperature changes to be an audio file.

If you sampled hourly or more often, then it should do fine
as a TamTam instrument. :-)

There is no usable text editor anyway. (BTW, if a Terminal
one will do, I suggest "joe". It's UTF-8 aware, can show a
help window while you work, is based on explicit block
operations rather than hidden ones, and it highlights the
current block.)

Anyway, a *.wav file is unquestionably efficient in every way.
This matters anywhere, but especially on the XO.

> > Fresh: hit frame button, click on activity
> >
> > Restart: hit home button, click on journal, spend time hunting
> > around in the disorganized mess, click to get the activity going,
> > manually delete the old data and restore default settings
> But consider, Restart: press search key, type 'temp', click to resume
> first (most recent) entry.  You've now opened the science lab on
> weather you started last Friday, with a couple temperature reading
> logs and all of the necessary settings restored as well, with no need
> for more setup overhead.

I could see that being desirable 1/3 of the time.

The rest of the time, a fresh start makes more sense.
For many activities, I almost can't imagine ever wanting
to restart. (Calculator, Connect...)

More information about the Sugar-devel mailing list