Re: [Libxtract-devel] libxtract, SC UGens and FFT

[Dan S. <dan...@el...>]

>> By the way, I've lost track: have you got MFCCs working to your 
>> satisfaction?
>>
> 
> Yes, as far as I can tell, it works as it should, and the vamp-libxtract
> plugin code is in sync with the 0.4.x API. You've probably noticed that
> you need to use the FFTW functionality to use xtract_mfcc(). However,
> the 'meat' of the MFCC implementation is in the filters, which are built
> with xtract_init_mfcc(). In your SC implementation you could construct
> the filters with libxtract, and then do the rest with yourself if you
> don't want the 'bloat' of linking to fftw just for this. 

No, that's fine, I'm happy to let libxtract do the work on this bit...


> Does SC have a  DCT ugen?

No, it doesn't.


A couple more MFCC questions, hope you don't mind:

Windowing: the xtract_mfcc method takes time-domain data in but doesn't 
seem to do any windowing, so I guess the windowing is expected to be 
handled before the data reaches libxtract. Is that right? It's possible 
that the filters somehow have the windowing implicit, but I'm guessing not.

Alloc'ing: I can see in the PD example how you're allocating memory for 
the mel filter, assuming "getbytes" is a PD realtime-malloc-type-thing. 
(Is t_float something PD-specific, or just the same as float?)

One thing that I'm wondering about is the malloc in the xtract_mfcc() 
method. I'm not sure why you malloc some new space to copy the data into 
- you don't seem to do anything there except read the data. Would it be 
safe to get rid of that malloc/memcpy/free? It might be a hangover from 
an older way of doing things.

Similarly there's a malloc in the DCT routine, not sure why that's 
needed. Maybe there's a reason for these that I've missed (thread safety?).

Best
Dan