Owen Green

I've been playing with a wrapper around this onset detection lib

- 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

- 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

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!)

- 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.

detect-inside-pfft

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.

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...

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

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.

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. 

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

> 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

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

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...

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;
>


Detect Inside pfft~