[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sc-devel] Machine Listening plans



2007/11/16, Click Nilson <clicksonnil@xxxxxxxxx>:
> Hi all,
>
> I wanted to outline my proposed changes to instantiate in the coming
> weeks, for comments and approval. These are being considered
> alongside the writing of my scbook chapter on this topic.
>
> 1. Potential removal of PV_HainsworthFoote and PV_JensenAndersen as
> outdated and not worth supporting (there are much better solutions now).

agree

> 2. Introduction of OSC messaging from Server of float arrays as a
> natural way to share data with the lang, circumventing the hazards of
> buffer polling (ie, you can send data only when an event is detected)

agree

> 3. Introduction of a series of new UGens with the prefix ML_, which
> run using the crossplatform FFT UGen or an equivalent* as their
> initial frontend. A new ML_UGens target would be added to the Xcode
> plugins project (I'd need help making the scons update).
>
> The following are already written and ready to commit:
>
> ML_AutoTrack //AutoTrack converted to run with FFT frontend
> ML_Loudness  //instantaneous loudness calculation in sones, using
> equal loudness contours and simple spectral and temporal masking

Cool, very very useful. What's the motivation for the ML_ prefix? Is
it to indicate that they hang off an FFT?  I'm not convinced the
prefix is necessary. I know there's the PV_ prefix convention already
in use, but I'm not sure the ML UGens necessarily need a new
'namespace'.

For my FFT statistics UGens I used an FFT_ convention - FFTCentroid,
FFTPower, etc - which I've stuck to, although I'm not sure that's
needed either. It makes for more typing and looks a little inelegant.


> A problem with the spectral machine listening work is supporting only
> one sample rate. I've found a way to support 44100, 48000, 88200 and
> 96000, which should be enough for some flexible use.
>
> And I'm drafting more, for example ML_Kitch (12TET major/minor key
> detection, though not good enough to commit at the moment), and could
> convert an ML_Concat, ML_AnalyzeEvents etc. I'd also be happy to
> discuss the addition of Dan's onset detection work to core, perhaps
> to FFT2_UGens?

My onset detection stuff has changed slightly. In order to use the
code in non-SC projects I've had to change it a little so it's a C
library rather than a disparate bunch of UGens. Still hangs off an FFT
rather than doing that internally. I'd be happy to put this code into
SC 3.2, and I do definitely think it'd be a good idea.

One remaining problem is to remove the assumption of 44.1kHz from
OnsetsDS, which I haven't tackled but maybe can be done in the same
way you have. Maybe we should discuss this more offlist.

Dan