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

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

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.

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

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?