In d_filter.c, the sample rate of filter blocks (lop~, bp~, biquad~, etc...) are generally set to a hard coded 44100 Hz (example: on line 277 where the bp~ class simply sets it with x->x_sr = 44100).

However, it is possible to run Pd at different sample rates, especially in libpd where the sample rate is passed in at init time.

How do filter blocks get access to this new sample rate, where does it get set in the code?

Actual sample rate comes from c_x and c_coef in struct hipctl and are of type t_sample which is buried at the bottom of d_ugen.c. Or that is what I am seeing, I am just starting to learn about digital filters and pd's pointer abuse often makes me go cross-eyed, but it is getting easier.

Edit: Should mention, I am mostly posting to see if I got it right. I don't really know but hope to be corrected and elaborated on.

Edit 2: I think i got it right and 44100 for x->xsr could be any number if the equations were tweaked to suit. But does the choice of 44100 have some logic behind it?

@oid said:

Actual sample rate comes from c_x and c_coef in struct hipctl and are of type t_sample which is buried at the bottom of d_ugen.c. Or that is what I am seeing, I am just starting to learn about digital filters and pd's pointer abuse often makes me go cross-eyed, but it is getting easier.

Edit: Should mention, I am mostly posting to see if I got it right. I don't really know but hope to be corrected and elaborated on.

Edit 2: I think i got it right and 44100 for x->xsr could be any number if the equations were tweaked to suit. But does the choice of 44100 have some logic behind it?

My guess is 44100 was picked because it's the "default" PD sample rate and is what CD quality is. However, some people use PD for things beyond music and run at different sample rates. PD allows you to select from 3 canned sample rates (44.1k, 48k, and 96k), or to set your own.

However what's not clear is how these different sample rates get into the filter blocks, which use x_sr for calculating their coefficients. If the sample rate changes aren't accounted for you'd get weird effects and your filter center frequencies and bandwidth wouldn't line up. Using an sr of 44.1k when you're running Pd at 48k might be barely noticeable, but it'd be a major effect if you're running at 96k or if you're running at 22050 Hz.

It appears, at least for bp~ and hip~, that the default SR is overwritten in their respective *_dsp() calls with:
x->x_sr = sp[0]->s_sr, which [hopefully] is set to the actual sample rate of the system.

Other filter objects appear not to use the x_sr member variable and instead just use s_sr directly.

@inari said:

However what's not clear is how these different sample rates get into the filter blocks, which use x_sr for calculating their coefficients.

But they also use c_coef and c_x which take current sample rate into account because they are type _samplerate. From d_ugen.c:

/* ------------------------ samplerate~~ -------------------------- */

static t_class *samplerate_tilde_class;

typedef struct _samplerate
{
    t_object x_obj;
    t_float x_sr;
    t_canvas *x_canvas;
} t_samplerate;

static void samplerate_tilde_bang(t_samplerate *x)
{
    outlet_float(x->x_obj.ob_outlet, canvas_getsr(x->x_canvas));
}

static void *samplerate_tilde_new(void)
{
    t_samplerate *x = (t_samplerate *)pd_new(samplerate_tilde_class);
    outlet_new(&x->x_obj, &s_float);
    x->x_canvas = canvas_getcurrent();
    return (x);
}

static void samplerate_tilde_setup(void)
{
    samplerate_tilde_class = class_new(gensym("samplerate~"),
        (t_newmethod)samplerate_tilde_new, 0, sizeof(t_samplerate), 0, 0);
    class_addbang(samplerate_tilde_class, samplerate_tilde_bang);
}

/* -------------------- setup routine -------------------------- */

void d_ugen_setup(void)
{
    block_tilde_setup();
    samplerate_tilde_setup();
}

I think if you do the math it will work out but I could be missing something, OOP in C plus heavy pointer use plus math symbols thrown about with pointer symbols always leaves me a but unsure of what is going on if not completely lost.

@oid said:

@inari said:

However what's not clear is how these different sample rates get into the filter blocks, which use x_sr for calculating their coefficients.

But they also use c_coef and c_x which take current sample rate into account because they are type _samplerate. From d_ugen.c:

/* ------------------------ samplerate~~ -------------------------- */

static t_class *samplerate_tilde_class;

typedef struct _samplerate
{
    t_object x_obj;
    t_float x_sr;
    t_canvas *x_canvas;
} t_samplerate;

static void samplerate_tilde_bang(t_samplerate *x)
{
    outlet_float(x->x_obj.ob_outlet, canvas_getsr(x->x_canvas));
}

static void *samplerate_tilde_new(void)
{
    t_samplerate *x = (t_samplerate *)pd_new(samplerate_tilde_class);
    outlet_new(&x->x_obj, &s_float);
    x->x_canvas = canvas_getcurrent();
    return (x);
}

static void samplerate_tilde_setup(void)
{
    samplerate_tilde_class = class_new(gensym("samplerate~"),
        (t_newmethod)samplerate_tilde_new, 0, sizeof(t_samplerate), 0, 0);
    class_addbang(samplerate_tilde_class, samplerate_tilde_bang);
}

/* -------------------- setup routine -------------------------- */

void d_ugen_setup(void)
{
    block_tilde_setup();
    samplerate_tilde_setup();
}

I think if you do the math it will work out but I could be missing something, OOP in C plus heavy pointer use plus math symbols thrown about with pointer symbols always leaves me a but unsure of what is going on if not completely lost.

The use of globals across multiple files in the PD source as well as the breaking of OOP principles by calling member functions of blocks that aren't used (looking at you osc~, vcf~ and cos~) amounts to a crime against humanity... A shame really. If you don't look at how the sausage is made, PD is a nifty little language, but the moment something breaks or needs to be extended, watch out...

@inari Opps, I conflated t_sample and t_samplerate, pretty sure I got myself turned around on C's OOP again as well. What global? Pd is more concerned about doing things in the most efficient way possible from the computation standpoint, hence all the pointers and the like, it often leads to less than ideal code from the reading perspective. Miller has a videos explaining the guts of pd in depth plus history/theory of this stuff, it is on his website under "classes" look for something like "inside pure data." The first couple videos unfortunately have an audio issue but you can mostly make out what is important, msp.ucsd.edu. There are also some older videos which can be found on the web, I don't think those have audio issues but no idea which is better, I have yet to have the time to sit down and watch through either in their entirety.

@oid

cos_table for one is a global pointer declared in m_pd, but used in d_osc.c...

It is set by a method that is a part of the [cos~] block, which both osc~ and cos~ call in their setups (really only one need do this), but osc~, cos~, and vcf~ all use the cos_table.

The fact that it's called by other blocks actually kind of breaks OOP, since the cos~ block's code is being invoked even if a cos~ block is never created.

@inari All the stuff for cos_table looks to be in d_osc.c for me, not finding anything grepping m_pd. What version of pd are you using? They did change some of this with 0.55.

actually kind of breaks OOP

I think part of the reason I have issues getting OOP down is because anytime I do a search looking for elaboration on something I always seem to find one of those big long largely philosophical discussions on OOP and get sidetracked, they are often started by a comment like yours.

Edit: looks like [vcf~] no longer calls cos_maketable but [osc~] still does.