Forums > Dev

Detect Inside pfft~

February 1, 2009 | 12:20 pm

Hello All,

I’ve been playing with a wrapper around this onset detection lib
http://onsetsds.sourceforge.net/, running inside pfft~. (To my surprise,
it works! First time!)

A couple of questions:

- Is there a standard way of determining whether an external is inside a
pfft~? It would be good to be able to throw an error to the user if not…

- Even better – would it be possible, in theory, to make an object that
could alter its behaviour depending on pfft~ / not-pfft~ context. The
lib in question can delegate fft duty to FFTW, so it would be pretty
awesome to have a single object that could behave sensibly in either
setting.

More generally:
- r_pfft.h /looks like/ it should be useful for this sort of lark, but I
couldn’t find any documentation in either the 4 or 5 sdks, or the list
archives.

Cheers,
Owen


February 1, 2009 | 5:52 pm

Quote: owen wrote on Sun, 01 February 2009 05:20
—————————————————-

> – Is there a standard way of determining whether an external is inside a
> pfft~? It would be good to be able to throw an error to the user if not…

t_pfftpub *pfft_parent = (t_pfftpub *)ps_spfft->s_thing;

if pfft_parent is 0 then you’re not in a pfft – if non-zero then you have a pointer to the public part of the pfft~ object as outlined in r_pfft.

> – Even better – would it be possible, in theory, to make an object that
> could alter its behaviour depending on pfft~ / not-pfft~ context.

If you call this in the new routine you can act accordingly, so yes. If you need vastly different perform routines then use a test in the dsp routine to add the suitable perform function.

Regards,

Alex


February 2, 2009 | 9:08 am

Quote: AlexHarker wrote on Sun, 01 February 2009 10:52
—————————————————-
> Quote: owen wrote on Sun, 01 February 2009 05:20
> —————————————————-
> If you call this in the new routine you can act accordingly…….

Just realised this might be a bit misleading – the test is only valid when the object is instantiated (when the new routine is called) – so to clarify you must do this in your new routine, but you can of course store the result in your object to use later.

Alex


February 2, 2009 | 4:14 pm

Thanks Alex,

After scratching my head as to how the ps_spfft symbol was being
retrieved I eventually found the fftinfo example in the 4.5.5 SDK, so
cheers for steering me in the right direction (again)!

I assume that in due course the v5 sdk will be as richly populated with
examples…


O

Alex Harker wrote:
> Quote: owen wrote on Sun, 01 February 2009 05:20
> —————————————————-
>
>> – Is there a standard way of determining whether an external is
>> inside a pfft~? It would be good to be able to throw an error to
>> the user if not…
>
> t_pfftpub *pfft_parent = (t_pfftpub *)ps_spfft->s_thing;
>


Viewing 4 posts - 1 through 4 (of 4 total)