Re: features saved in logs or other files?

1 view
Skip to first unread message

Matt Robbins

unread,
Jul 19, 2007, 2:53:40 PM7/19/07
to Peter J. Dugan, xbat-...@googlegroups.com
Hey Peter,

  Unfortunately, the state of the Measurement interface is quite primitive compared with most of the others.  At the moment, each measurement lives in a single file in the "Extensions\Measures\Event" directory.  You can make as many of them as you want.  Just copy one of the examples (quartiles_measurement.m or moments_measurement.m) and save it using the same name pattern (<measure_name>_measurement.m).  It should get picked up when you start up a sound browser.  A word of warning though: this stuff is pretty old and probably won't be forwards compatible.  We'll have a new measurement interface soon, so programming new ones will be a lot more like programming a feature, filter or detector is now.

Hope this helps.  You should just be able to change the code in an existing measurement at a few places to get a new one going.  By the way.  I'm also forwarding this to the xbat-devel group.  These are all great questions that other potential developers should be able to check out too.

-Matt

 

On 7/19/07, Peter J. Dugan <pj...@cornell.edu> wrote:
Now that you mention this, Tim mentioned "measurements" the other day; hard to get the lingo straight.  no matter.

I see an option (pull down) in XBAT that says

Measure->TimeFrequency Moments

or

Measure->Time-Freq Qualtrils

Are these the measures you refer to?

If so, can we add others? how?



-----Original Message-----

> Date: Thu Jul 19 12:17:56 EDT 2007
> From: "Matt Robbins" < matthew...@gmail.com>
> Subject: Re: features saved in logs or other files?
> To: "Peter J. Dugan" <pj...@cornell.edu >
>
> Hey Peter,
>
>    You're totally correct, but I think that we may have a different notion
> of what a "feature" is. We already have an extension type called a
> "measurement" that can compute values (which I think many people might
> consider to be "features") and store them in logs.   These values can be
> computed based on the raw input data, or on any combination of what we call
> "features"  -- things like an amplitude envelope, spectrogram, wavelet
> scalogram, or just about anything that has a value associated with every
> point in time.   Our "features" are not stored because they are generally
> used to compute other things, and are themselves computed on demand.  We
> have thought about making them store-able, but in many cases it would be
> impractical (particularly very large datasets for which sufficient storage
> might not be available).
>
> So maybe once you create your wavelet feature, you can also implement a
> bunch of the features that I know you have already as measurements?
>
> Cheers,
> Matt
>
>
>
> On 7/19/07, Peter J. Dugan <pj...@cornell.edu > wrote:
> >
> > Matt,
> >
> > I noticed that there are some parameters saved in the Amplitude Feature.
> >
> > These are:
> > feature.rms.value = A1;
> > feature.abs.value = A2;
> > feature.max.value = A3;
> >
> > Is this "feature" struct saved with the given sound ?  Perhaps in a log?
> >
> > Thoughts:  If we could extract features from various sounds, then we
> > should be able to read features from saved structures/logs?
> >
> >


Reply all
Reply to author
Forward
0 new messages